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INTRODUCTION 

• 

The  requirement  for  data  sharing  occurs  in  many  computer  appli- 
cation areas.  Examples  are  hospital  networks,  banking  systems, 
reservation  systems,  and  government  information  systems.  These 
systems  accumulate  large  volumes  of  information  which  are  of  interest 
to  a large  community  of  users.  As  a result,  the  large  data  bases  be- 
come much  too  large  for  feasible  duplication  for  various  applications. 

In  addition,  utilizing  the  same  information  for  different  applications 
often  necessitates  restructuring  of  data,  a process  that  is  both  time 
consuming  and  expensive.  Therefore,  there  is  a growing  need  for  on- 
line and  real-time  data  sharing.  This  requirement  is  best  satisfied  by 
the  facilities  provided  with  computer  networking.  As  a result  of  com- 
puter networking.  Very  Large  Data  Bases  (VLDBs)  are  logically  feasi- 
ble where  each  local  data  depository  (at  a given  network  node)  can  be 
thought  of  as  a small  logical  data  set  of  the  VLDB.  It  seems  reason- 
able to  speculate  here  that  most  VLDBs  to  be  constructed  over  the  next 
five  years  will  be  formed  through  computer  networking  of  smaller  resi- 
dent data  base  management  systems.  This  seems  inevitable  due  to  the 
excessive  costs  associated  with  alternatives  to  networking;  i.  e.  , data 
base  duplication  and/or  restructuring. 

Although  computer  networking  is  a viable  solution  to  the  growing 
need  of  online  data  sharing,  it  also  creates  a problem  with  respect  to 
the  actual  utilization  of  dissimilar  data  bases.  This  problem  can  best 
be  described  as  a "multi-user  interface"  problem.  The  user  interfaces 
referred  to  here  are  those  of  data  standards,  sign-on  procedures,  data 
base  query  languages,  and  logical  data  structures.  Data  standards 
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refer  to  the  form  in  which  data  are  represented;  i.  e.  , how  they  are 
placed  into  the  system  and  in  what  form  they  are  displayed.  User 
sign-on  procedures  refer  to  the  "login"  sequences  that  each  data  base 
management  system  requires;  i.  e.  , how  one  acquires  access  to  a data 
base  management  system  as  well  as  to  the  individual  data  bases  con- 
tained in  it.  Logical  data  structures  are  those  structures  in  which  a 
user  views  the  data,  as  opposed  to  a physical  data  structure;  i.  e.  , the 
form  in  which  the  data  are  physically  stored  in  the  system.  Finally, 
data  base  query  languages  are  the  sets  of  statements,  commands,  and 
control  sequences  which  a user  employs  to  access  a data  base.  Almost 
always,  a query  language  is  couched  around  a set  of  logical  data  struc- 
tures; i.  e.  , a user's  queries  are  constructed  in  an  environment  com- 
posed of  logical  data  structures. 

An  inherent  problem  with  data  bases  shared  via  computer  network- 
ing is  the  proliferation  of  these  user  interfaces.  Each  interface  must 
be  mastered  by  individual  users  of  the  network.  This  problem  is  well 
recognized  and  has  been  the  subject'of  a number  of  studies.  Re- 
cently, Logicon  completed  a study  of  a multi-language  problem  occur- 
ring in  the  Community  Online  Intelligence  Network  System  (COINS). 
Currently,  a C^INS  user  must  employ  three  different  user  data  lan- 
guages to  query  the  48  intelligence  data  files  provided  through  COINS  I. 
COINS  II,  which  utilizes  an  ARPANET  technology,  is  scheduled  to 
be  expanded  by  one  new  system  per  year  so  that  the  intelligence  com- 
munity will  be  able  to  access  100  — 150  files  supported  by  8 — 10  sys- 
tems within  the  next  live  years.  Unfortunately,  each  of  these  systems 
has  its  own  query  language,  with  the  result  that  COINS  users  will  be 
required  to  learn  8 — 10  query  languages  if  they  wish  to  query  these 
files.  Further,  because  each  data  base  query  language  is  implemented 
using  a different  data  base  management  system,  even  the  interpretation 
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for  a query  to  duplicate  files  on  different  systems  will  vary.  Finally, 
because  each  system  supports  different  types  of  terminals,  the  user  is 
forced  to  learn  terminal -unique  characteristics  in  order  to  access  dif- 
ferent systems  within  the  community. 

ADAPT,  which  stands  for  ARPA  Data  Base  Access  and  presenta- 
tion Terminal,  forms  a basis  for  a production  prototype  intelligent 
terminal  which  will  provide  network  users  and/or  other  systems  a 
uniform  interface  for  accessing  online  data  bases  on  a multitude  of 
dissimilar  systems.  Initially  the  ADAPT  system  (which  is  briefly  de- 
scribed in  the  next  section)  has  been  developed  with  a particular  net- 
work in  mind  (i.  e.  , COINS);  however,  it  must  be  stressed  here  that  the 
technologies  developed  and  refined  during  this  effort  are  portable  to 
other  similar  ''m\ilti-user  interface"  problems  that  currently  exist  on 
other  networks;  i.  e.  , ARPANET,  Intelligence  Data  Handling  Systems 
(IDHS),  etc. 

• 

The  remainder  of  this  report  consists  of  five  additional  sections 
and  an  appendix.  The  next  section  describes  the  ADAPT  project  and 
the  four  phases  proposed  for  it  during  its  on-going  development.  The 
third  section  provides  a specification  of  the  ADAPT  I Uniform  Data 
Language  (DDL),  including  its  logical  data  structures  and  statement 
and  command  set.  This  section  presents  the  data  base  query  language 
available  to  ADAPT  I users.  The  fourth  section  provides  a specifi- 
cation of  the  ADAPT  I Data  Definition  Language  (DDL)  that  is  available  to 
the  ADAPT  I superuser  for  data  base  definition.  The  fifth  section  pro- 
vides a specification  of  the  ADAPT  I Transformation  Definition  Lan- 
guage (TDL)  available  to  the  ADAPT  I superuser  for  transformation 
specific  data  definition.  The  last  section  details  the  error  diagnostics 
and  messages  that  might  occur  during  the  operation  of  ADAPT  I. 
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Finally,  an  appendix  (appendix  A)  is  provided  which  presents  a specifi- 
cation for  an  expanded  UDL  statement  set  that  is  envisioned  for  the 
completed  ADAPT  system,  phases  I — IV. 

Although  the  primary  purpose  of  this  document  is  to  present  a 
specification  of  the  Uniform  Data,  Data  Definition,  and  Transformation 
Definition  Languages  supported  by  ADAPT  I,  it  seems  appropriate  to 
provide  adequate  introductory  material  for  those  readers  who  are  not 
familiar  with  the  proposed  ADAPT  system  and  its  inception. 


I 
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ADAPT  DESCRIPTION 

Originally  the  ADAPT  project  was  conceived  as  being  comprised 
of  three  developmental  phases,  ADAPT  I,  ADAPT  II,  and  ADAPT  III. 
The  first  two  phases  were  to  be  production  prototypes  only,  the  actual 
production  model  not  appearing  until  the  third  phase  of  development. 
The  purpose  of  this  section  is  to  briefly  define  each  ADAPT  phase, 
outlining  the  hardware /software  suite  to  be  used  in  its  development  as 
well  as  presenting  the  user's  capabilities  provided  with  each.  A new 
phase,  ADAPT  IV,  is  also  proposed. 

The  ADAPT  system  is  being  developed  in  San  Diego,  at  the  Tacti- 
cal and  Training  Systems  Division  of  Logicon.  The  hardware  configur- 
ation currently  utilized  for  this  phased  development  consists  of  the 
following  devices: 

a.  Digital  Equipment  Corporation  (DEC)  PDP-11/45  with  65K 
parity  core  memory. 

b.  LA36  DECWRITER  H console. 

c.  RKll  1.  2M-word  RK05  disk  drive  and  controller. 

d.  Two  RK05  1.  2M-word  disk  drives. 

e.  Tally  4300,  300-lpm  (96-character  ASCII)  medium  speed 
printer. 

f.  Three  MiniBEE-4  CRT  terminals. 

g.  ACC  Very -Distant -Host  Interface  (VDH-llC)  for  ARPANET 
connection. 

Although  this  equipment  suite  is  somewhat  modest,  it  does  provide 
an  excellent  environment  for  initial  ADAPT  development. 
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ADAPT  I has  been  developed  as  processes  under  UNIX  (an  operating 
system,  developed  at  Bell  Laboratories).  UNIX  and  its  accompanying 
subsystems  furnish  ADAPT  developers  an  excellent  set  of  soft- 
ware including  a sophisticated  time-sharing  environment,  compiler- 
compilers,  various  compilers  and  assemblers,  sophisticated  text 
editors,  debugging  packages,  etc.  The  major  processes  developed  for 
ADAPT  I have  been  implemented  using  C language.  Also,  the  LR(1) 
compiler -compiler  (YACC)  has  provided  much  of  the  front-end  process- 
ing for  ADAPT.  The  ADAPT  development  center  in  San  Diego  is  a 
"very-distant-host"  on  the  ARPANET. 

ADAPT  I's  purpose  is  essentially  three-fold:  first,  the  develop- 
ment of  the  fundamental  ADAPT  system  architecture  within  a PDP-11  / 
UNIX  environment;  second,  the  development  of  a basic  language  trans- 
formation technology;  and,  third,  the  demonstration  that  language 
transformations  as  developed  can  be  exercised  properly  through  net- 
work protocols. 

Although  the  ADAPT  I effort  is  a very  important  and  extensive 
phase,  much  of  the  software  "products"  produced  during  this  phase  are 
invisible  to  the  ADAPT  I user.  The  actual  user  interfaces  that  are 
supported  in  ADAPT  I are  relatively  minimal,  with  most  software  tech- 
nology being  applied  to  developing  the  internal  fundamental  system 
architecture  that  forms  the  basis  for  subsequent  phases.  However, 
from  a user's  point  of  view,  ADAPT  I provides  a limited  but 
useful  set  of  capabilities.  First  of  all,  as  was  stated  earlier  in  the  in- 
troduction, the  actual  ADAPT  I implementation  is  based  on  a par- 
ticular network  and  on  a fixed  set  of  data  base  management  systems 
resident  on  this  network.  The  network  is  the  Community  Online  Intelli- 
gence Network  System  (COINS),  and  the  four  data  base  management 
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systems  residing  on  it  are  the  DMS-1 100/QLiP  system,  the  Defense 
Intelligence  Agency  On-Line  System  (DIAOLS),  the  SIGINT  On-Line 
Information  System  (SOLIS),  and  the  Technical  Information  Processing 
Systems  (TIPS/TILE).  Based  on  the  resiilts  from  a previous  contract, 
Logicon  has  developed  a set  of  language  transformations  which  map  a 
single  data  b^se  query  language  (UDL,  a language  developed  by  Logi- 
con) to  a set  of  eight  different  data  base  query  languages.  At  the  time 
of  this  analysis,  three  of  the  eight  languages  were  installed  on  the 
COINS  network  and  the  remaining  five  were  future  candidates  for  net- 
work residency.  This  set  of  language  transformations  involved  three 
separate  areas:  logical  data  structure  transformations,  data  base 
query  transformations,  and  data  base  maintenance  transformations. 
ADAPT  I provides  implementations  of  the  transformations  for  the 
first  two  areas:  data  structures  and  queries.  The  third  set  of  trans- 
formations will  be  provided  in  ADAPT  II.  The  next  section  of  this 
report  presents  a specification  of  the  user  language,  UDL,  that 
is  required  to  support  the  four  initial  transformations  provided 
in  ADAPT  I.  As  can  be  readily  seen,  ADAPT  I UDL  is  somewhat  com- 
plete as  far  as  data  structures  and  data  base  query  facilities  are  con- 
cerned, but  is  essentially  void  in  areas  dealing  with  report  generation, 
data  base  maintenzince  and  data  manipulation. 

Another  important  user  interface  supported  in  ADAPT  I is  a 
facility  for  redefining  existing  target  system  files  into  logical 
structures  compatible  with  UDL.  This  facility  is  called  the  Data  Defi- 
nition Language  (DDL)  and  is  detailed  in  the  fourth  section  of  this  report. 

Required  with  the  schemas  generated  by  DDL  are  a set  of  trans- 
formation files  which  provide  host- specific  file  information  required 
for  the  transformations.  The  Transformation  Definition  Language 
(TDL)  subsystem  provides  this  interface  and  is  detailed  in  the  fifth 
section  of  this  document. 
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FmaUy.  ADAPT  I provides  limited  but  useful  faculties  for  display- 
mg  data  received  from  a given  target  system  (as  the  consequence  of  a 
previous  UDL  query),  the  ability  to  display  the  logical  structure  of 
a file,  and  other  more  system  control-oriented  facilities. 

adapt  II  is  a significant  upgrade  to  ADAPT  I as  far  as  direct  user 
faculties  are  concerned,  although  it  is  still  considered  only  as  a pro- 
duction prototype.  One  of  the  major  products  of  the  ADAPT  n effort 
will  be  the  completion  of  the  language  transformation  set;  i.  e.  , the 
mclusion  of  a set  of  language  transformations  for  data  base  main- 
tenance faculties.  These  transformations,  as  in  ADAPT  I,  will  be  for 
the  four  target  systems  listed  previously.  Other  ADAPT  11  features  are: 

a.  Sophisticated  display  and  report  generation  facUity. 

b.  Local  record  sort  facUity. 

c.  Expanded  data  structure  mapping  facility. 

d.  Complete  fUe  guide  capabUity. 

e.  Improved  user  access  control  interfaces. 

As  the  new  ADAPT  II  products  are  developed,  the  UDL  developed 
in  ADAPT  I expands  accordingly  to  accommodate  the  new  user  inter- 
faces. Appendix  A presents  a complete  specification  of  UDL.  a UDL 
that  will  become  fully  realized  at  the  completion  of  ADAPT  UI.  As  can 

be  readily  seen,  the  ADAPT  I UDL  is  a direct  subset  of  the  language 
specified  in  appendix  A. 

ADAPT  m will  provide  yet  additional  user  interfaces,  although  its 
mam  purpose  is  to  convert  the  production  prototype  system  as  devel- 
oped m AD.\PT  II  to  two  production  models.  The  first  production 
model  wUl  be  installed  at  various  network  service  centers,  and  the 
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second  model  will  exist  as  a free-standing  intelligent  terminal  imple- 
mented using  then-current  microprocessor  and  "small"  mass  memory 
technology.  The  user  interface  improvements  developed  in  ADAPT  UI 
will  provide  a complete  data  manipulation  capability  for  the  user.  This 
will  include  programming  language -like  facilities,  such  as  local  vari- 
able declarations,  numeric  expression  and  assignment  statement 
facilities,  and  program  and  loop  control  facilities.  Refer  to  appendix 
A,  paragraph  A.  4.  5,  for  more  information. 

ADAPT  IV,  as  conceived  here,  will  provide  ADAPT  users  with  a 
local  data  base  management  capability.  It  must  be  remembered  that, 
although  the  first  three  phases  of  ADAPT  supply  the  user  with  a com- 
plete uniform  data  base  management  query  language,  users  can  not 
define  and  create  new  files  at  their  installations.  All  files  physically 
reside  at  the  various  target  systems  throughout  the  network.  It  is 
interesting  to  point  out  here  that  the  same  Data  Definition  Language 
(DDL)  provided  in  ADAPT  I can  be  used  to  define  new  files  which  will 
exist  locally  at  the  user's  installation.  Of  course,  what  will  be  re- 
quired for  ADAPT  IV  is  a data  base  manager  to  manipulate  these  files 
(i.  e.  , local  data  base  interrogations,  display,  maintenance,  backup/ 
recovery,  etc.  ) and  mass  storage  to  accommodate  the  local  files. 

The  remaining  sections  constitute  a detailed  specification  of  the 
ADAPT  I UDL  statement  and  command  set  and  the  DDL  and  TDL  sub- 
systems. Although  this  document  is  a language  specification  and  not  a 
user's  manucil  per  se,  it  is  complete  such  that  an  individual  familiar 
with  computers  and  one  or  more  programming  languages  can  utilize 
it  as  the  latter. 
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UNIFORM  DATA  LANGUAGE  (UDL)  FOR  ADAPT  I 

Introduction 

This  section  provides  a specification  for  the  subset  of  the  Uniform 
Data  Language  (UDL)  available  for  ADAPT  I.  The  commands  available 
for  ADAPT  I are  edso  described  in  this  section,  even  though  they  are 
not  considered  a true  part  of  the  UDL  proper.  Although  commands  are 
an  important  integral  of  any  system,  they  are  usually  implementation- 
dependent,  since  their  utility  is  very  specialized.  In  line  with  this, 
one  can  usually  think  of  UDL  data  structures  and  statements  in 
more  abstract  terms,  essentially  removed  from  implementation 
considerations. 

The  format  of  this  section  essentially  parallels  that  of  appendix  A, 
but  of  course  is  considerably  briefer  since  the  initial  ADAPT  I UDL 
is  a small  subset  of  the  complete  UDL. 

Briefly,  one  can  see  that  a fairly  complete  data  structure  com- 
plement is  being  provided  in  ADAPT  I as  well  as  a complete  data  base 
interrogation  capability.  However,  the  remaining  capabilities  are 
limited  to  a somewhat  restricted  display  facility  with  no  data  base 
maintenance  or  data  manipulation  interfaces  provided.  These  missing 
capabilities,  as  mentioned  earlier  in  this  report,  will  be  provided  in 
subsequent  ADAPT  phases. 

The  information  which  follows  is  divided  into  four  basic  groups: 

a,  Basic  definitions. 

b.  Data  structures. 
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c.  UDL  statements. 

d.  ADAPT  I commands. 

Basic  definitions  provides  descriptions  of  the  character  set  and 
the  construction  of  names  and  labels.  Data  structures  are  described 
with  respect  to  their  logical  structure,  designated  data  types,  and  as- 
signed data  attributes.  UDL  statements  and  ADAPT  I commands  are 
described  and  their  syntax  and  semantics  provided  in  detail. 

Basic  Definitions 

This  paragraph  presents  the  fundamental  definitions  for  the 
ADAPT  I UDL.  Included  are  character  set,  data  name,  and  label 
definitions,  and  descriptions  of  the  three  data  constants.  These  defi- 
nitions, and  their  syntax  and  semantics,  will  be  referenced  throughout 
the  remainder  of  this  section. 

CHARACTER  SET  — The  American  Standard  Code  for  Information 
Interchange  (ASCII)  is  the  character  set  adopted  for  ADAPT  I 
UDL.  Out  of  this  character  set,  the  following  delimiters,  digits,  and 
letters  are  valid  for  ADAPT  I UDL  statement  construction. 

Syntax  — 

<delimiter>  = + | - | / | ( j ) | , [ . | ' | A | % ] ; | CR 

<digit>  = 0ll|2|3l4|5|6|7|8|9 

<letter>  = A|B|C|D1E|F|G|H|I|J[K|L1m|N| 

0(P(Q|R|S|  T(U|V|W(X|Y|Z 

Semantics  — The  meaning  of  each  of  the  delimiters  is  as  follows: 

I 

+ : unary  plus  operator. 

-:  unary  minus  operator. 
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/:  geographic  constant  delimiter. 

(:  list  or  grammaticed.  enclosure  (initial). 

):  list  or  grammatical  enclosure  (terminal). 

, : list  separator. 

. ; decimal  point. 

' : delimit  (initial  and  terminal)  character  constant. 

A:  designates  a space. 

%:  denotes  geographic  constant. 

terminates  statements  and  commands 
CR;  carriage  return  (newline) 

Decimal  digits  are  used  to  express  numeric  constants,  to  form 
labels  and  names  (except  as  the  first  character),  and  to  form  charac- 
ter and  geographic  constants. 

A letter  may  be  any  letter  of  the  alphabet.  Letters  may  be  used 
in  labels,  names,  and  in  character  and  geographic  constants. 

NAMES  AND  LABELS  — Names  and  labels  are  ADAPT  1 UDL 
identifiers  which  are  constructed  by  the  user.  Following  are  the  syn- 
tax and  semantics  of  UDL  names  and  labels. 

Syntax — 

<name>  = <name>  <letter>  j <name>  <digit>  | <letter> 

<label>  = <name> 

<tag>  = <label> 

Semantics  — A name  can  consist  of  up  to  eight  characters,  where 

these  characters  must  be  either  letters  or  digits.  The  first  character 
must  be  a letter.  Names  are  used  to  identify  various  entities  in  an 
ADAPT  I UDL  statement  complex.  All  syntactically  correct  names  are 
valid  constructs  in  ADAPT  I UDL  except  for  those  occurring  in  the 
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reserved  word  list  in  table  1.  For  obvious  reasons,  the  complete  re- 
served word  list  for  all  of  UDL  is  shown  here  (Note:  entries  without  an 
asterisk  are  applicable  for  ADAPT  I). 

Names  can  be  utilized  in  two  basic  ways:  pure  names  or  as  part  of 
other  identifiers.  Pure  names  can  occur  as  either  a list  name  or  as  a 
data  base  structure  name;  i.  e.  , file-name,  field-name,  etc.  Names 
can  also  be  used  to  form  labels. 

Labels  are  user-defined  identifiers  that  are  located  in  the  front  of 
ADAPT  I UDL  statements.  The  use  of  labels  is  optional  except  where 
otherwise  noted.  Labels  that  are  referenced  in  ADAPT  I UDL  state- 
ments are  called  tags. 


TABLE  1.  ADAPT  I UDL  RESERVED  WORD  LIST. 


ACTION 

DECLARE” 

FIND 

LT 

POSITION 

TAB* 

ADD* 

DELETE 

FORMAT* 

MAX* 

PROCEDURE* 

TABSET* 

ALD* 

DEP 

GE 

MODE 

PULL* 

THEN* 

ALONG 

DESCEND* 

CEO 

MV 

PUT* 

TO* 

AND 

DISPLAY 

GOTO* 

NKEY 

QUIT 

TRAILER* 

ARRAY 

DO* 

GT 

NOR 

REC* 

TRANFILE 

AT* 

E* 

HEADER* 

NOT 

RECORD* 

TRANS 

ATT 

EARRAY 

KSP* 

NUM 

REMOTE 

TREE 

BATCH 

ECHO 

IF* 

NUMERIC* 

REMOVE* 

TRESET* 

BY* 

ELSE* 

IN 

OCC* 

RETURN* 

USE* 

CALL* 

END* 

INPUT* 

OCCURRENCE* 

RGROUP 

V 

CAT* 

EPROC* 

INSIDE 

OFF* 

ROUTE 

val* 

CHANCE* 

EQ 

INTER 

ON* 

RTYPE* 

validate 

CHAR 

ERCROUP 

INV 

OPEN 

SAVE 

value* 

CIRCLE 

ESCHEMA 

KEY 

OR 

SCHEMA 

VERT* 

CLEAR* 

ETRAN 

LABEL 

ORC 

SKIP* 

VIEW 

CLOSE 

EXECUTE 

LE 

OUTPUT* 

SORT* 

VIS 

CONTAINS* 

EXIST* 

LINE* 

OUTSIDE 

SOURCE 

WORD* 

CREATE* 

EXIT* 

UST 

PAGE* 

SPACE* 

WRG 

CURRENT* 

FIELD 

LOCAL 

POLY 

SV 

XOR 

DATABASE 

FILE 

LOCSC* 

PCS 

the  syntax  and  semantics  for  all  legal  ADAPT  I UDL  data  constants 
and  expressions.  Three  basic  data  constants  are  recognized:  charac- 
ter-constants, numeric -constants,  and  geographic-constants. 


Syntaix  — 
<data-constant> 

<character-constant> 

<characters> 


<numeric-constant> 

<nvime  ric-clause> 

<intege  r> 

<sign> 

<geographic-constant> 

<lat-term> 

<po  s ition- te  rml  > 
<degreel> 

<min-sec> 

t 

<min> 

<sec> 

<directionl> 

<long  -term> 

<position-term2> 

<degree2> 

<direction2> 


= <character-constant>  | <numeric- 
constant>  | <geographic-constant> 

= '<characters>' 

= <letter>  <characters>  | <digit> 

<characters>  | <delimiter>  <characters>  | 
<letter>  | <digit>  1 <delimiter> 

= <numeric-clause>  | <sign>  <numeric- 
clause> 

= <integer>  • <integer>  | <integer>  • 1 
• <integer>  | <integer> 

= <digit>  <integer>  | <digit> 

= +1  - 

= % <lat-term>A/<long-term> 

= <position-terml>  <directionl> 

= <degreel>A  <min-sec>  | <degreel> 

= <digit>  <digit> 

= <min>  A <sec>  | <min> 

= <degreel> 

= <degreel> 

= N 1 S 

= <position-term2>  <direction2> 

= <degree2>  A <min-sec>  | <degree2> 

= <digit>  <degreel> 

= E I W 
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<expression> 


<field-term> 

<field-name> 

<subscript-list> 

<subscript> 

<file-name> 

<a  r ray- name  > 

<repeating-group-name> 

<list-name> 


<fieid-term>  ( <file-name>  | <array- 
name>  | <repeating-group-name>  | 
<list-name>  | <data-constant> 
<field-name>  (<subscript-list>)  | 
<field-name> 

<name> 

<subscript>,  <subscript>,  <subscript>  | 
<subscript>,  <subscript>  ( <subscript> 
<integer> 

<name> 

<name> 

<name> 

<name> 


Semantics  — For  ADAPT  I UDL  data  structures,  character-con- 
stants are  applicable  for  character  data  types  only.  Numeric -constants 
are  valid  in  data  structures  with  numeric  data  types  only,  and 
geographic-constants  are  valid  in  data  structures  with  geographic  data 
types. 

Expressions  in  ADAPT  I UDL  are  composed  only  of  names  and 
data-constants.  In  later  ADAPT  phases,  full  algebraic  expressions 
will  be  made  available. 

Data  Design 

This  paragraph  describes  the  data  structures,  data  types,  and 
data  attributes  recognized  in  ADAPT  I UDL.  There  exist  five  primary 
data  structures  in  ADAPT  I UDL: 

a.  Field. 
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b.  Aggregate. 

c.  Record. 

d.  File. 

e.  Data  base. 

Data  types  are  associated  with  the  lowest  level  data  structure,  the 
field,  and  three  basic  types  are  defined: 

a.  Character. 

b.  Numeric. 

c.  Geographic. 

Along  with  data  types,  access  attributes  are  also  associated  with 
each  field,  and  control  access  with  respect  to  interrogation  and  display. 

The  remainder  of  this  paragraph  discusses  the  foregoing  in  detail. 

DATA  STRUCTURES  — Five  primary  data  structures  are  recog- 
nized in  ADAPT  I UDL:  data  bases,  files,  records,  aggregates,  and 
fields.  The  most  important  structures  with  respect  to  user  utilization 
and  overall  ADAPT  I UDL  design  considerations  are  fields  and  aggre- 
gates. These  two  structures  will  be  discussed  first. 

Fields  — Two  field  structures  are  recognized  in  ADAPT  I UDL: 

a.  Single -valued  field. 

b.  Multivalued  field. 

The  two  fields  are  discussed  in  the  following  paragraphs,  where 
their  logical  structure  and  rules  governing  their  access  with  respect 
to  interrogation  and  display  are  described. 

Single -Valued  Field  — A single-valued  field  has  the  logical  struc- 
ture depicted  in  figure  1.  It  has  a name  with  which  is  associated  a 


j 
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Figure  1.  Logical  Structure  of  a Single -Valued  Field. 

single  value  occurrence.  All  references  to  a single -valued  field  must 
reference  its  name.  The  value  associated  with  a single -valued  field 
must  conform  to  the  data-type  defined  for  that  field. 

A single-valued  field  can  be  interrogated  by  referencing  its  name 
against  some  relational  condition  where  a match  is  successful  depend- 
ing on  its  single-valued  occurrence. 

Multivalued  Field  — A miiltivalued  field  has  the  logical  structure 
depicted  in  figure  2.  It  has  a name  with  which  is  assoeiated  a set  of 
value  occurrences.  All  references  to  a multivalued  field  must  refer- 
ence its  name.  Each  value  occurrence  of  a multivalued  field  must 
conform  to  the  data-type  defined  for  that  field.  The  number  of  value 
occurrences  that  can  be  contained  in  a multivalued  field  is  arbitrary, 
and  either  no  occurrences  or  many  occurrences  are  possible. 


field-name 

value  j 

• • • 

valuCjj 

Figure  2.  Logical  Structure  of  a Multivalued  Field. 
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A multivalued  field  can  be  interrogated  by  referencing  its  name 
against  a relational  condition  where  a match  is  successful  depending 
on  a value -by -value  search  of  the  value  occurrence  set  contained  in  the 
field.  When  a multivalued  field  is  displayed,  all  of  its  occurrences 
are  shown. 

Aggregates  — An  aggregate  is  a named  collection  of  fields  and/or 
other  aggregates.  This  named  collection  of  data  structures  can  occur 
an  arbitrary  number  of  times  within  a record.  One  occurrence  of  such 
a collection  is  called  a data  set.  Since  aggregates  may  contain  other 
aggregates,  complex  hierarchical  structures  can  be  formed  with  them. 
A collection  of  data  sets  belonging  to  the  same  aggregate  and  having 
the  same  ancestral  occurrence  of  a parent  aggregate  is  called  an  ag- 
gregate instance. 

In  most  cases,  an  aggregate  is  a structural  convenience  since  the 
aggregate  itself  cannot  be  referenced  specifically  for  reading  or  writ- 
ing data.  There  exist  exceptions  to  this,  however,  where  aggregates 
can  be  referenced  as  a totcility.  Generally  these  exceptions  deal  with 
convenience  modes  in  data  display. 

.'Aggregates  do  not  have  specific  data  types  or  data  attributes  as- 
sociated with  them.  Since  an  aggregate  can  have  an  arbitrary  number 
of  fields  defined  for  it,  it  may  have  many  data  types  and  data  attributes. 
Two  aggregate  data  structures  are  defined  in  ADAPT  I UDL: 

a.  Array. 

b.  Repeating  group. 

The  following  paragraphs  discuss  these  aggregates  in  detail. 
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Array  — An  array  is  a named  multivalued  data  structure  which  can  | 

be  composed  of  any  number  of  fields  or  arrays.  An  array  has  the  j 

logical  structure  depicted  in  figure  3.  Repeating  groups  cannot  be  part  j 

of  an  array  definition.  At  least  one  field  must  be  defined  in  an  array.  | 

An  arbitrary  number  of  occurrences  of  an  array  data  set  is  legal,  but  j 

j 

the  maximum  number  of  occurrences  must  be  established  as  part  of  the  j 

array's  definition.  | 

An  array  cannot  be  interrogated  as  a totality,  since  references  are  | 

restricted  to  actual  fields  defined  for  that  array.  For  each  array  de-  | 

fined  in  a record,  an  index  is  associated  with  it.  This  index  has  the  | 

range*'  1 — n where  n is  the  number  of  occurrences  defined  for  that  ar-  | 

ray.  All  query  references  to  fields  defined  in  an  array  must  be  accom-  | 

panied  by  this  index.  Since  arrays  can  be  nested,  other  implied  sub-  j 

scripts  are  also  required.  That  is,  if  a given  array  is  defined  under  two 


Figure  3.  Logical  Structure  of  an  Array  (two  array  levels 
are  shown). 
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other  arrays,  three  subscripts  must  be  specified  in  its  field  references 
Array-name  references  are  only  legal  for  display  where  an  entire  ar- 
ray can  be  displayed. 

Repeating  Group  — A repeating  group  is  a named  multivalued  data 
structure  which  can  be  composed  of  any  number  of  fields,  arrays,  or 
other  repeating  groups.  A repeating  group's  logical  structure  is  de- 
picted in  figure  4.  At  least  one  field  must  be  defined  in  a repeating 
group.  An  arbitrary  number  of  occurrences  of  a repeating  group  data 
set  is  legal. 


frepeating- 
group- 
^ namel 


field-namel 


value 


repeating 


name2  / 


repeating 


\ namez 


field-name2 


value 


field-nanic2 


va  1 ue 


field-name2 


value 


Figure  4.  Logical  Structure  of  a Repeating  Group  (two 
repeating  group  levels  are  shown). 
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A repeating  group  cannot  be  interrogated  as  a totality,  since  ref- 
erences are  restricted  to  actual  fields  defined  for  that  repeating 
group.  Since  repeating  groups  are  pure  multio  ecu  ring  data  structures, 
an  arbitrary  nximber  of  occurrences  is  allowed,  and  this  number 
may  be  variable  for  each  record  (the  size  of  an  array  is  fixed  for  all 
records). 

Record  — Records  are  probably  ADAPT  I UDL's  next  most  im- 
portant data  structure  since  they  form  the  physical  unit  of  selectability. 

Individual  records  are  not  named.  Records  are  defined  by  the  fields 
and  aggregates  defined  under  them.  All  records  in  a file  have  the 
same  logical  structure  containing  the  same  fields  and  aggregates. 

This  does  not  necessarily  imply  that  all  records  are  the  same  size; 
true  multi  occur  ring  data  structures  such  as  multivalued  fields  or  re- 
peating groups  can  have  an  arbitrary  number  of  occurrences  for  any 
record. 

Files  — A file  is  a named  collection  of  records.  A file  is  the 
largest  data  structure  which  an  interrogation  statement  can  reference. 

^ • Data  Base  — A data  base  is  a collection  of  files,  and  can  be  rough- 

ly thought  of  as  synonymous  with  a given  target  system. 

• 

DATA  TYPES  — Data  types  designate  the  nature  of  the  data  that  a 
field  contains.  ADAPT  I UDL  data  types  can  be  of  three  basic  types; 
character,  numeric,  and  geographic.  Fields  containing  character  i 

data  can  be  referenced  with  the  EQ  relational  operator  only.  Numeric  ^ 

data  types  specify  that  a field  contains  data  of  a purely  numeric 
nature.  For  fields  designated  with  a numeric  data  type,  the  EQ  oper- 
ator plus  all  the  standard  relational  operators  (i.  e.  , GT,  LT,  etc.  ) 

' are  valid.  The  special  geographic  data  type  is  for  fields  that  contain 

geographic  data.  Geographic  data  always  contain  the  positional  dyad 
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latitude /longitude.  The  special  geographic  operators,  INSIDE,  OUT- 
SIDE, and  ALONG,  are  used  exclusively  with  fields  designated  with  a 
geographic  data  type. 

All  ADAPT  I UDL  fields  must  have  a designated  data  type.  All  con- 
stants referenced  in  conj\mction  with  these  fields  must  conform  to  this 
data  type.  Refer  to  the  definition  of  ADAPT  I UDL  data  constants. 

DATA  ATTRIBUTES  — Data  attributes,  as  data  types,  are  associ- 
ations placed  on  fields.  Data  attributes  affect  a field's  operability  with 
the  ADAPT  I UDL  statement  set.  Two  attribute  classifications  must 
be  designated  for  an  ADAPT  I UDL  field; 

a.  Interrogation. 

b.  Display. 

The  interrogation  attribute  can  be  one  of  three  kinds;  keyed,  non- 
keyed,  and  dependent.  Fields  with  a data  attribute  of  keyed  can  be 
referenced  in  any  FIND  statement.  That  is,  there  are  no  restrictions 
to  their  use  in  selection  criteria.  A field  designated  as  dependent  can 
also  be  utilized  in  a FIND  statement.  However,  this  must  be  a depend- 
ent FIND  statement  where  its  record  source  is  from  a previous  FIND 
statement.  Therefore,  a field  designated  as  dependent  cannot  be  ref- 
erenced in  an  initial  FIND  statement.  Fields  designated  as  nonkeyed 
cannot  be  referenced  in  a FIND  statement. 

« 

The  display  attribute  can  be  one  of  two  kinds;  visible  or  invisible. 
Fields  designated  with  a data  attribute  of  visible  can  be  displayed  via 
the  DISPLAY  statement.  Fields  designated  invisible  cannot  be  dis- 
played  at  all.  A field  cannot  be  simultaneously  invisible  and  nonkeyed 
since  the  field  could  be  neither  queried  nor  displayed,  i.  e.  , could  not  be 
referenced  in  any  way. 
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ADAPT  I UDL  Statements 

INTRODUCTION  - For  the  first  phase  of  ADAPT,  ADAPT  I,  only 
two  UDL  statements  are  available:  the  FIND  statement  and  the 
DISPLAY  statement.  The  FIND  statement  provides  ADAPT  I users 
with  a fairly  complete  data  base  interrogation  facility  (as  is  apparent 
when  compared  to  paragraph  A.  4.  2 in  appendix  A). 

On  the  other  hand,  the  DISPLAY  statement  provided  for  ADAPT  I 
gives  users  only  a limited  display  capability,  restricted  to  UDL 
default  format  only.  Although  this  display  facility  is  somewhat  re- 
stricted by  lacking  user-specified  format  control,  it  does  provide  the 
user  with  a means  of  displaying  desired  data  in  an  orderly  fashion. 

INTERROGATION  STATEMENT  — Interrogation  statements  in 
ADAPT  I UDL  are  used  to  isolate  records  from  a file  by  specifying  a 
set  of  selection  criteria  against  that  file.  Interrogation  does  not  dis- 
play a file  but  only  isolates  records  for  subsequent  display.  This 
paragraph  describes  the  synteix  and  semantics  of  ADAPT  I UDL's  in- 
terrogation facility,  the  FIND  statement. 

FIND  <source-clause>  <selection-criteria>; 
IN  <file-name>  ( SOURCE  (<tag>) 
<selection-clause>  OR  <selection-criteria>  | 
<selection-clause> 

<selection-phrase>  AND  <selection-clause>  | 
<selection-phrase> 

<selection-factor>  <log-op>  <selection- 
phrase>  | <selection-factor> 

XOR  I NOR 


<find-statement>  = 

<source-clause>  = 

<selection-criteria>  = 

<selection-clause>  = 

<selection-phrase>  = 

<log-op>  = 
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} 


i 


<selection-£actor> 

<selection-primary> 

<scope-qualifier> 

<selection-term> 

<rel-terml> 

<rel-opl> 

<rel-term2> 

<rel-op2> 

<rel-terin3> 

<rel-op3> 

<geo-exp> 

<circle-exp> 

<poly-exp> 

<route-exp> 

<lat-long-list> 

<radius  -te  rm> 
<band-term> 


NOT  <selection-£actor>  ( <selection-primary> 
<scope-qualifier>  (<selection-criteria>)  | 
(<selection-criteria>)  ( <selection-term> 

< r e pe  ating  - g roup  - name  > 

<rel-terml>  ( <rel-term2>  | <rel-term3> 
<field-term>  <rel-opl>  <data-constant> 

EQ  I GT  1 LT  1 GE  1 LE 

<field-term>  <rel-op2>  <numeric  constant>, 
<numeric  constant> 

WRG  1 ORG 

<field-term>  < rel-op3>  <geo-exp> 

INSIDE  I OUTSIDE  | ALONG 
<circle-exp>  [ <poly-exp>  | <route-exp> 
CIRCLE  (<radius-term>,  <geographic 
constant>) 

POLY  (<lat-long-list>) 

ROUTE  ( <band -te  rm>,  <lat-long-list>) 
<geographic-constant>,  <lat-long-list>  [ 
<geographic-constant> 

<numeric-constant> 

<nume  ric-consteUit> 


Semantics  — The  source-clause  must  specify  either  a file- 
name or  a statement  label  of  a previous  FIND  statement.  FIND 
statements  which  reference  other  FIND  statements  are  called  depend- 
ent FIND  statements  since  they  isolate  records  from  a set  of  records 
previously  isolated  by  another  FIND  statement.  The  selection- 
criteria  is  a specialized  boolean-expression  used  exclusively 


’ i 


• I 
I ; 
' ! 
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for  record  selection.  Legal  boolean  operators  for  selection-criteria 
are  OR.  AND,  XOR.  NOR.  and  NOT.  and  their  definition  and  operation 

precedence  is  as  follows: 

a.  OR  — boolean  "inclusive-or"  condition  (union). 

A OR  B 

0 0 0 

0 1 1 

1 1 0 

1 1 1 

b.  AND  — boolean  "and"  condition  (intersection). 

A AND  B 

0 0 0 

0 0 1 

1 0 0 

1 1 1 

c.  XOR  — boolean  "exclusive -or"  condition. 

A XOR  B 

0 0 0 

0 1 1 

1 1 0 

1 0 1 

d.  NOR  — boolean  "joint-denial"  condition  (not-or). 
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e.  NOT  - boolean  "complement"  condition  (negation). 

NOT  A 

1 0 

0 1 

Boolean  operator  precedence  is  the  following; 

a.  NOT. 

b.  XOR,  NOR. 

c.  AND. 

d.  OR. 

The  boolean  operators  XOR  and  NOR  are  evaluated  "left-to- right. 
The  use  of  parentheses  is  valid  in  selection- criteria  and  forces  prece- 
dence inside  their  scope.  Parentheses  may  be  nested  and,  if  so,  eval- 
uation proceeds  from  the  innermost  parenthesis  level  outwards. 

The  argument  of  a boolean  term  (called  a selection-primary)  can 
be  either  a selection-term,  which  is  composed  of  three  relational  term 
types,  or  other  selection-criteria  enclosed  in  parentheses  with  an  op- 
tional scope -qualifier.  For  any  given  set  of  selection-criteria,  the 
maximum  scope  of  operation  is  over  a record.  This  is  called  a 
selection-criteria's  implicit  scope.  For  complex  hierarchical  struc- 
tures within  a record,  it  is  also  desirable  to  be  able  to  limit  scopes  of 
operation  to  various  subtrees  of  the  structure.  The  scope -qualifier 
has  been  designed  to  do  this. 

The  scope -qualifier  must  be  the  name  of  a repeating  group.  A 
selection-criteria  qualified  by  a scope -qualifier  is  forced  to  satisfy 
that  criteria  for  the  same  occurrence  of  the  named  repeating  group. 
This  also  implies  that  the  field-terms  referenced  in  the  qualified 
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selection-criteria  must  be  defined  directly  for  the  named  repeating 
group.  The  sc  ope -qualifier  will  affect  the  selection  process  .result 
only  if  there  exist  two  or  more  selection-primaries  as  arguments  of 
the  scope-qucilifier  such  that  one  or  more  of  the  logical  connectors 
is  an  AND  (after  the  selection-criteria  has  been  reduced  to  disjunctive- 
normal-form). 

Scope-qualifiers  can  also  be  nested  to  force  the  desired  lineage 
path  during  the  selection  process. 

Since  the  scope-qualifier  is  only  applicable  for  criteria  which  are 
connected  by  an  AND  operator,  complex  selection-criteria  can  be  dif- 
ficult to  analyze  with  respect  to  a scope -qualifier.  Complex  selection- 
criteria  under  the  scope  of  a repeating  group  can  be  reduced  to  a more 
understandable  form  with  the  application  of  three  rules; 

a.  Reduce  the  selection-criteria  to  disjunctive -normal-form. 

b.  Distribute  the  scope -qualifier  through  the  various  disjuncts. 

c.  Drop  the  scope -qualifier  from  any  single-term  disjunct. 

The  result  is  a series  of  scope -qualified  terms  or  unqualified 

single-terms,  connected  by  OR-operators.  (note;  steps  b-c  above 
convert  the  expression  to  a scope-normal-form. 

Relational  terms  can  be  divided  into  three  basic  groups: 

a.  Standard  relational  terms. 

b.  Range  relational  terms. 

c.  Geographic  relational  terms 
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Standard  Relational  Terms  — Five  standard  relational  operators 
are  legal  in  ADAPT  1 UDL  selection-criteria  (see  figure  5): 

LT  — data -specification  less  than  numeric-constant. 

' GT  — data-specification  greater  than  numeric-constant.  j 

LE  — data-specification  less  than  or  equal  to  numeric -constant.  ! 

I 

. t 

GE  — data-specification  greater  than  or  equal  to  numeric -constant. 

EQ  — data-specification  equals  data-constant  (numeric  or  . ; 

[ character). 

(Range  Relational  Terms  — Two  operators  are  provided  for  range 

operations;  WRG  and  ORG.  The  WRG  operator  requires  that  the 
f field-term  be  within  or  equal  to  the  limits  established  by  the  two 

).  specified  numeric-constants.  The  first  expression  specifies  the  lower 

^ range  limit,  and  the  second  expression  specifies  the  upper  range 

I limit.  The  ORG  range  requires  that  the  field-term  be  outside  the 

t range  established  by  the  two  numeric -constants. 


1 

Operator 

Data  Types 

Character 

Nume  ric 

Geographic 

EQ 

Yes 

Yes 

— 

LT,  GT,  LE,  GE,  WRG, 

ORG 

— 

Yes 

— 

INSIDE,  OUTSIDE,  ALONG 

— 

— 

Yes 

Figure  5.  Legal  Combinations  of  Data  Types  and  Selection- 
Criteria  Relational  Operators. 
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Geographic  Relational  Terms  — Geographic  relational  terms  apply 
to  field-terms  (with  a geographic  data  type)  and  their  relationship  to  a 
specified  set  of  circles,  routes,  or  n-sided  polygons  on  the  surface  of 
the  earth.  Three  geographic  operators  and  three  specialized  geo- 
graphic-expressions  are  recognized  in  UDL. 

The  INSIDE  operator  requires  that  a field-term's  geographic  value 
(latitude /longitude  constajit)  be  inside  the  circle  or  the  polygon  specified 
by  the  geographic -expression.  Similarly,  the  OUTSIDE  operator  re- 
quires that  a field-term's  value  be  outside  the  polygon  specified,  «uid  the 
ALONG  operator  requires  that  the  value  specified  in  the  field-term  be  on 
the  perimeter  of  the  specified  route.  The  specialized  geographic - 
expression  can  appropriately  specify  either  a circle,  an  n-sided  polygon, 
or  a multiple  directioned  route.  For  a circle,  both  the  center  and  radius 
must  be  established.  A route  is  established  by  specifying  the  points  it 
lies  on  and  the  width  of  the  route.  Polygons  are  determined  by  a list 
of  latitude /longitude  specifications.  Refer  to  the  data-constant  descrip- 
tion for  the  syntax  and  semantics  of  geographic -constants. 

DISPLAY  STATEMENT  — The  data  presentation  facility  provided 
in  ADAPT  I is  limited  to  UDL  default  format.  In  this  version,  the 
user  will  neither  be  able  to  establish  headers  or  trailers  nor  generate 
sophisticated  reports  tailored  with  user- specified  format  declarations. 
Following  are  the  syntax  and  semantics  for  the  ADAPT  I UDL  DISPLAY 
statement. 
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t 

[ 


L 


Syntax  — 


<display-  statement> 
<display-clause> 

<di  splay- list> 

<display-eleinent> 

<aggregate-name> 

<source-arg> 


= DISPLAY  <display-clause> ; 

= SOURCE  (< source -arg> ) <display-li8t>  I 
SOURCE  source -arg> ) 

= < display- eleinent>,  <display-list>  | <display- 
element> 

= <field-terin>  1 <aggregate-name>  1 TREE 
(<aggregate-name>)  | <character-constant> 

= <repeating-group-name>  I <array-name> 

= <tag>  I <listname> 


Semantics  — The  DISPLAY  statement  operates  on  a list  of  records. 
These  records  may  be  on  a user-specified  list  or  they  may  be  on  an 
implicit  list  generated  by  a FIND  statement.  If  a display-list  is  not 
specified,  the  entire  record(s)  is  displayed. 


The  display-list  is  a list  of  data  structures  below  the  record  level 
which  provides  the  user  with  a selective  and  ordered  mechanism  for 
displaying  portions  of  a record.  The  fundamental  element  of  a display 
list  is  the  display -element.  Display- elements  can  be  one  of  four  basic 
kinds;  a character-constant,  a field-term,  an  array-name,  or  a re- 
peating-group-name. In  addition,  an  entire  repeating  group  or  array 
may  be  displayed  by  using  the  TREE  qualifier.  If  a display-list  is 
present,  at  least  one  display- element  other  than  character- constant 
must  be  specified. 
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Each  display- element  is  displayed  in  UDL  default  display  format. 
This  format  provides  a simple  means  for  a user  to  display  fields  and 
aggregates  of  records.  Figure  6 illustrates  the  actual  UDL  default 
format  as  it  applies  to  the  various  kinds  of  fields  and  aggregates.  Due 
to  the  inherent  nature  of  hierarchical  structures,  records  which  con- 
tain levels  of  aggregates  will  be  displayed  with  the  tree  structure  in- 
tact, regardless  of  the  order  of  the  specified  display-items.  Data 
structures  defined  for  the  same  aggregate,  however,  will  be  displayed 
in  the  order  they  are  specified  in  the  display-list.  An  aggregate 
display- element  will  cause  the  display  of  all  occurrences  of  the  specified 
aggregate  at  its  data  set  level  only;  that  is,  subordinate  aggregates 
will  not  be  displayed.  An  aggregate  display-element  qualified  by  TREE 
behaves  as  the  situation  just  described  except  that  all  subordinate  ag- 
gregates are  also  displayed  (as  shown  in  figure  6). 

If  a list  of  field-terms  is  specified  as  a set  of  display-elements  and 
they  are  embedded  in  a hierarchical  structure  of  aggregates,  the 
entire  upper  tree  structure  which  encompasses  all  the  specified  field- 
terms  will  be  displayed.  Aggregate  names  will  also  be  displayed 
as  node  markers,  and  will  be  inserted  into  the  proper  places  of  the 
tree.  Combinations  of  field-terms,  repeating-group-names,  aind 
array-names  may  be  specified  in  the  same  display-list.  The  display 
for  each  display- element  behaves  as  shown  in  figure  6.  Each  record  dis- 
played will  contain  the  minimum  tree  structure  which  encompasses 
the  display- elements.  As  brought  out  earlier  in  this  section,  if  a dis- 
play-list is  not  specified,  the  entire  record  is  displayed.  Thus  if 
aggregates  are  present  in  the  record  definition,  the  entire  tree 
structure  will  be  displayed. 
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Single- Valued  Field 

field-name  = value 

Multivalued  Field 

field-name  = value  j 
= value  2 

= valuBjj 

Array  (TREE  (array-namel)) 
array-namel  (1) 

field-name  = value 
array-nameZ  (1,  1) 

field-name  = value 
field-name  = value 
array-nameZ  (1,  Z) 

field-name  = value 
field-name  = value 
array-namel  (Z) 

field-name  = value 
array-nameZ  (Z,  1) 

field-name  = value 
field-name  = value 
array-nameZ  (Z,  Z) 

field-name  = value 
field-name  = value 

Repeating  Group  (TREE  (repeating-group-namel)) 
Repeating  g roup-name  1 
field-name  = value 
fie  Id -name  = value 

Figure  6.  UDL  Default  Display  Format  (Sheet  1 of  Z). 
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repeating  group-nameZ 
field -name  = vadue 

repeating  group-name3  '■ 

field-name  = value  j 

I 

repeating  group-name 3 

t 

field -neUTve  = value  ] 

\ 

repeating  group-name  1 ] 

field-name  = value  i 

! 

field-name  = value  j 

i 

repeating  group-nameZ 
fie  Id -name  = value 

Figure  6.  UDL  Default  Display  Format  (Sheet  Z of  Z). 

ADAPT  I Commands 

INTRODUCTION  — This  paragraph  provides  a final  speci- 
fication for  user  commands  available  under  ADAPT  I.  Generally, 
commands,  as  contrasted  to  statements,  are  more  implementation - 
dependent  and  their  utility  is  based  on  specific  users  and  the  hardware/ 
operating  system  suite  under  which  the  system  exists.  Therefore,  as 
user  requirements  become  more  defined  and  as  experience  is  gained 
with  the  ADAPT  I/UNIX  environment,  it  is  expected  that  this  set  of 
commands  will  be  altered  and/or  expanded.  The  dichotomy  between 
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statements  and  commands  discussed  here  is  important  since  it  mini- 
mizes the  proliferation  of  UDL  "dialects.  " Commands  allow  system 
designers  to  customize  systems  for  individueil  users  without  having  to 
alter  more  fundamental  language  constructs  (in  this  case,  UDL  state- 
ments and  data  structures).  This  makes  the  fundamental  language 
constructs  "portable"  from  application  to  application;  i.  e.  , they  are 
standardized. 

Following  are  the  syntax  and  semantics  for  ADAPT  I commands. 

ADAPT  COMMAND  — The  ADAPT  conunand  provides  entry  into 
the  ADAPT  I system. 

Syntax  — 

<adapt-command>  = ADAPT 

Semantics  - After  users  have  successfully  logged  onto  the  TAS 
system,  their  terminals  are  constantly  monitored  by  a TAS  command 
interpreter  called  the  TAS  Shell.  The  ADAPT  process  is  called  by  the 
TAS  Shell  program  when  users  enter  the  ADAPT  command.  ADAPT 
validates  that  the  user  is  a valid  ADAPT  user,  and  if  this  is  the  case, 
the  ADAPT  I EXEC  is  called  to  process  the  UDL  statements /commands. 
If  the  user  is  not  a valid  ADAPT  user,  the  user  is  duly  informed  and 
returned  to  the  TAS  Shell  (technically,  the  ADAPT  commeind  is  a TAS 
command,  not  an  ADAPT  command). 

QUIT  COMMAND  - The  QUIT  command  provides  an  exit  from 
the  ADAPT  I system  and  returns  the  user  to  the  TAS  environment. 

Syntax  — 

<quit-command>  = QUIT; 

Semantics  — When  users  choose  to  leave  ADAPT  I,  they  must  enter 
the  QUIT  command.  This  command  returns  the  user  to  the  TAS 
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Shell  program.  At  this  time,  the  user  may  choose  to  utilize  other 
TAS  subsystems. 

Although  the  user  has  left  ADAPT,  the  lists  generated  by  him 
(via  the  SAVE  command)  are  retained  by  ADAPT  I under  the  user's 
identifier.  Also,  any  logical  transaction  responses  which  may  be 
received  from  the  network  for  the  user  are  saved  by  ADAPT  I for 
later  perusal  by  the  user. 

OPEN  COMMAND  — The  OPEN  command  specifies  the  file(s)  that 
a user  wishes  to  access. 

Syntax  — 

< open -commands  = OPEN  <file -name -list> ; 

<file-name-list>  = <file-name>,  <file-name-list>  \ <file-name> 

Semantics  — Users  may  open  one  or  more  files  during  an  ADAPT  I 
session.  A file  must  have  been  opened  prior  to  its  reference  via  an 
ADAPT  I FIND  statement.  The  primary  purpose  behind  the  OPEN 
command  is  to  establish  overall  access  privileges  of  the  user  and  the 
user's  terminal  with  respect  to  the  host  where  the  file  resides  and 
to  the  actual  file  specified. 

CLOSE  COMMAND  — The  CLOSE  command  closes  one  or  more 
files  from  future  access. 

Syntax  — 

<close-command>  = CLOSE  <file -name -list>;  | CLOSE; 
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Semantics  — Users  may  close  one  or  more  files  during  their 
ADAPT  I session  by  using  the  CLOSE  command.  The  entry  of  CLOSE 
without  a file-name-list  closes  all  open  files.  When  users  exit  (refer  to 
QUIT  command),  all  their  open  files  are  automatically  closed. 

EXECUTE  COMMAND  - The  EXECUTE  command  allows  ADAPT  I 
users  to  input  statement /command  sequences  from  a predefined  text  file. 

Syntax  — 

<execute-command>  = EXECUTE  TRANFILE  <execute-clause> ; ( 

EXECUTE  SCHEMA  <execute-clause> ; I 
EXECUTE  <execute-clause> ; 

<execute-clause>  = <character-constant>  ECHO  I 

<character-  constant> 

Semantics  — The  <character-constant>  following  EXECUTE  is  the 
name  of  a user-defined  text  file  which  contains  a series  of  ADAPT  I 
statement /command  sequences.  ADAPT  I retrieves  directives  from 
this  file  until  the  file  is  exhausted  and  then  returns  control  to  the  user's 
terminal.  ECHO  is  an  optional  specification  which,  if  present,  results 
in  the  statement /command  sequences  being  echoed  back  to  the  terminal. 
If  ECHO  is  not  present,  the  statement /command  sequences  are  not 
output.  At  all  times,  error  diagnostics  which  may  occur  are  directed 
to  the  terminal.  If  the  user  suspects  errors  may  be  present,  it  is 
wise  to  specify  ECHO  since,  otherwise,  the  error  diagnostics  are  not 
associated  with  the  incorrect  statements. 

MODE  COMMAND  — The  MODE  command  allows  an  ADAPT  I 
user  to  either  specify  that  statement /command  sequences  are  to  be 
processed  fully  or  are  to  be  checked  only  for  syntactic  and  semantic 
errors. 
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Syntax  — 

<mode-command>  = MODE  <mode-arg>; 

<mode-arg>  = VALIDATE  | ACTION 

Semantic s — The  MODE  command  with  an  argument  of  VALIDATE 
requests  ADAPT  I to  accept  all  following  statements  and  commands  for 
syntactic  euid  semantic  validation  only.  Only  a MODE  command  with  an 
argument  of  ACTION  restores  ADAPT  to  its  normal  processing  state. 
When  a user  logs  onto  ADAPT  I,  the  system  is  in  an  action  mode. 

When  the  system  is  in  the  validate  mode,  no  commands  are  processed, 
with  the  exception  of  the  MODE  and  EXECUTE  commands. 

VIEW  COMMAND  — The  VIEW  command  allows  a user  to  display  files 
and  file  schema  definitions  defined  in  ADAPT  I,  names  of  lists  currently 
defined  for  that  user,  and  names  of  labels  used  during  the  current  ADAPT 
session. 

Syntax  — 

<view-command>  = VIEW<view-clause>; 

<view-clause>  = SCHEMA  (<file -name> ) | LIST  1 LABEL  | FILE  | 

TRANFILE  (<file-name> ) | TRANS  1 TRANS 
(<trans- number  >) 

<trans-number>  = <integer> 

Semantics  — The  VIEW  command  allows  the  user  to  display  various 
types  of  information  concerning  his  or  her  transactions  via  ADAPT,  and 
the  file  structures  defined  for  ADAPT.  Six  option- specifiers  exist 
for  the  view  command:  SCHEMA,  LIST,  LABEL,  FILE,  TRANFILE, 
and  TRANS. 
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The  files  defined  for  ADAPT  are  listed  when  a user  inputs  the 
VIEW  FILE  command.  With  the  VIEW  SCHEMA  command,  a user  can 
display  a schema  for  a specific  file  defined  in  ADAPT  I.  This  display 
is  quite  similar  to  that  of  the  UDL  default  format  since  the  file  schema 
is  presented  as  an  indented  tree  structure  (if  the  file  contains  hierarchical 
structures).  Of  course,  instead  of  field  values,  each  field's  data  type, 
access  attributes  and  size  are  provided.  The  VIEW  TRANFILE  can  be 
used  by  the  superuser  to  peruse  the  transformation  data  of  an  ADAPT 
file.  The  data,  basically  the  UDL  and  the  host  names  for  the  file's 
aggregates  and  fields,  are  displayed  in  the  indented  tree  format.  If  the 
file  is  positional  in  nature,  the  position  data  and  the  number  of  occur- 
rences (if  a field  is  multivalued)  are  output  along  with  the  names  of 
each  field. 

Users  may  also  view  the  list-names  and  labels  currently  defined  for 
them  by  specifying  VIEW  LIST  and  VIEW  LABEL.  Users  may  ascertain 
the  current  statuses  of  their  transactions  with  batch  hosts  via  the  VIEW 
TRANS  command.  The  output  from  this  command  contains  the  trans- 
action numbers,  associated  filenames  and  statuses.  If  the  user  specifies 
a transaction  number  at  the  end  of  the  VIEW  TRANS  command,  the 
output  is  dependent  upon  the  status  of  the  transaction  and  the  contents 
of  the  original  request.  If  the  status  of  the  transaction  is  something  other 
than  answered  (ANSR),  an  error  message  is  output.  Otherwise,  if  the 
user  had  done  a SAVE,  a hit  count  is  output;  if  the  user  had  done  a 
DISPLAY,  the  hit  count  and  the  requested  data  are  output  for  the  user's 
perusal. 

SAVE  COMMAND  — The  SAVE  command  allows  users  to  save 
actual  file  records  transmitted  across  the  network. 

Syntax  — 

<save-command>  = SAVE  SOURCE  (<tag>)  <list-name>; 
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Semantics  — Users  may  save  entire  records  that  were  isolated  by 
a previous  FIND  statement.  The  tag  is  a label  of  a FIND  statement,  and 
list-name  is  a name  to  be  associated  with  the  list  of  saved  records.  This 
name  is  local  for  the  user  and  cannot  duplicate  an  existing  list-name  or 
label.  Lists  of  records  may  be  displayed  in  part  or  in  entirety  with  a 
UDL  DISPLAY  statement.  List-names  associated  with  the  user  may  be 
displayed  with  a VIEW  LIST  command. 

DELETE  COMMAND  — The  DELETE  command  is  used  to  delete 
file  schemas,  tranfiles  and  user  lists. 

Syntax  — 

<delete-coinmand>  = DELETE  <delete-clause>  ; 

<delete-clause>  = SCHEMA  (<file-name>)  | LIST  (<list-name> ) j 

TRANFILE  (<file-name> ) 

Semantics  — File  schemas  and  tranfiles  that  exist  in  ADAPT  I can 
be  removed  from  the  system  by  the  superuser  with  the  DELETE  com- 
mand. The  deletion  of  a file  schema  also  deletes  that  file's  tranfile,  if 
it  exists.  Lists  assigned  to  the  user  initiating  the  DELETE  LIST  com- 
mand can  be  removed  from  the  system,  freeing  mass  storage  space  and 
the  list -name. 


1 
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ADAPT  I DATA  DEFINITION  LANGUAGE  (DDL) 

Introduction 

The  Data  Definition  Language  (DDL)  provides  the  ADAPT  I superuser 
with  the  facility  to  define  files  for  subsequent  use  with  the  Uniform  Data  | 

Language  (UDL).  All  files  which  are  to  be  referenced  with  UDL  under 
ADAPT  I (although  they  are  resident  in  the  various  data  bases  connected  ' | 

to  the  network),  must  have  their  logical  organization  be  made  known  to  j 

ADAPT  I in  order  for  ADAPT  I to  generate  appropriate  language  trans-  | j 

formations.  DDL  provides  a definition  of  a file  in  terms  of  UDL  data  | 

structures,  not  in  terms  of  the  data  structures  of  the  actual  target  | | 

systems. 

DDL  generates  dictionary  definitions  for  each  file  defined.  These 
definitions  can  be  deleted  and/or  replaced  with  new  definitions  whenever 
a file's  structure  is  modified  at  its  resident  host. 

Syntax 

< schema- statements  <schema-clause> 

ESCHEMA; 

SCHEMA  <file-name>  <database-type> ; 

LOCAL  1 REMOTE  (BATCH)  ( REMOTE 
(INTER) 

<field-def-blk>  <aggregate-def-blk>  | 

<field-def-blk> 

<aggre gate -definitions  <aggregate-def- 
blkS  [ <aggregate -definitions 

<array-definitionS  [ <rg-definitionS 

< fie  Id -definitions  <field-def-blkS  | <field- 
definitionS 

FIELD  <field-nameS  <field-clauses ; 


< schema  - definitions 

< schema  - statements 
< database -types 

< schema -clauses 

<aggregate-def-blkS 

<aggregate- definitions 
<field-def-blkS 

< field -definitions 
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<field-clause> 

• 

<field-type>  <data-type>  ATT  (<interro- 
att>,  <disp-att>)  <size-clause> 

<field-type> 

= 

SV  1 MV 

<data-type> 

= 

CHAR  1 NUM  1 GEO 

<interro-att> 

= 

KEY  ( NKEY  | DEP 

<disp-att> 

= 

VIS  1 INV 

< size-clause> 

= 

<integer>  | V 

<array-de£inition> 

= 

<array-3tatement>  <field-def-blk> 
EARRAY; 

<array-statement> 

= 

ARRAY  <array-clause> ; 

<array-clause> 

S 

<array-name>  <array-size>  <parent- 
name>  1 <array-name>  <array-size> 

<array-size> 

= 

<integer> 

<parent-name> 

= 

<array-name>  ( <repeating-group-name> 

<rg-definition> 

= 

<rg-statement>  < field -de£-blk>  ERGROUP; 

<rg-statement> 

= 

RGROUP  <rg-clause> ; 

<rg-clause> 

< repeating- group-name>  <rg-parent- 
name>  1 <repeating-group-name> 

<rg-parent-name> 

= 

< r e pe  atin  g - g r oup  - name> 

Semantics 

For  completeness,  the  foregoing  syntax  shows  DDL  schema  con- 
structs as  a total  definitional  block.  In  practice,  the  schema  is  produced 
as  a set  of  ordered  DDL  statements.  A DDL  sequence  is  indicated  by 
the  schema- statement.  The  schema- statement,  denoted  by  SCHEMA, 
contains  a required  database -type.  The  schema- statement  contains 
a file -name  (up  to  eight  characters)  and  the  mode  of  operation  of  the 
data  base  where  the  file  resides  The  data  base  is  either  local  (LOCAL) 
or  a distant  (REMOTE)  target  host  system,  whose  mode  of  operation  is 
either  batch  (BATCH)  or  interactive  (INTER).  The  DDL  sequence  is 
terminated  with  an  end- schema  statement,  ESCHEMA. 
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F ollowing  the  schema- statement  is  the  schema-clause,  a block 
of  data  structure  definitions  making  up  the  file's  logical  structure.  The 
schema-clause  contains  two  basic  types  of  definitions:  those  defining 
fields  and  those  defining  aggregates.  Aggregate  definitions  are  optional, 
depending  on  whether  they  exist  within  a file,  but  a field  definition  block 
is  mandatory.  That  is,  every  file  has  a basic  data  set  which  contains  at 
least  one  field.  The  basic  data  set  definition  must  occur  first  in  the 
schema-clause.  This  definition  block  is  formed  from  a sequence  of 
field-definition- statements.  Afield  definition  statement  is  indicated 
by  the  token  FIELD  followed  by  the  field's  name  (up  to  eight  characters) 
and  a field-clause.  All  field  names  must  be  unique  within  a file.  The 
mandatory  field-clause  specifies  the  field's  type,  its  data-type,  access 
attributes,  and  size.  Two  types  of  fields  exist  in  UDL,  single-valued 
fields  indicated  by  SV  and  multivalued  fields  indicated  by  MV.  Following 
the  specification  of  the  field-type  is  the  data-type  specification.  Three 
data-type s are  recognized  in  UDL:  character,  denoted  as  CHAR; 
numeric,  denoted  as  NUM;  and  geographic  data  type,  GEO.  As  with  the 
field-type,  a data-type  must  be  specified.  Each  field  also  has  associated 
with  it  an  interrogation  attribute  and  a display  attribute.  Attribute  speci- 
fications are  indicated  by  the  token  ATT.  Valid  interrogation  attributes 
are  KEY,  for  fields  which  can  be  referenced  in  any  FIND  statements; 
NKEY  (non-key),  for  fields  which  cannot  be  referenced  in  FIND  state- 
ments; and  DEP  (dependent)  for  fields  which  can  only  be  referenced  in 
dependent  FIND  statements.  Two  display  attributes  are  recognized  in 
UDL:  visible  (VIS)  and  invisible  (INV).  The  maximum  field  width  (as 
an  ASCn  representation,  regardless  of  the  data  type)  must  be  specified 
for  each  field.  For  single-valued  and  invisible  multivalued  fields  which 
contain  true  variable  length  character  strings,  such  as  extensive  text,  a 
V may  be  substituted  for  the  width  specification.  In  most  situations, 
however,  the  field  width  should  be  specified. 
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If  aggregates  are  present  in  a file,  they  must  be  defined  following 
the  basic  data  set  definition  block.  Aggregates  are  defined  as  either 
arrays  or  repeating  groups.  An  array  definition  block  begins  with  an 
array- statement,  denoted  by  ARRAY.  The  array- statement  specifies 
the  array's  name  (up  to  eight  characters),  its  order,  and,  optionally, 
its  parent's  name.  The  order  specifies  the  maximum  number  of  occur- 
rences allowed  for  the  array.  The  parent  name  is  the  name  of  another 
aggregate,  either  a repeating  group  or  another  array.  If  a parent  name 
is  not  specified,  the  array  belongs  to  the  basic  data  set.  Following  the 
array- statement  is  a mandatory  field-definition-block.  At  least  one 
field  must  exist  for  an  array.  Following  the  field -definition-block  is  an 
end-array  statement,  denoted  by  E ARRAY,  terminating  the  array's 
definition. 

A repeating  group  definition  block  begins  with  a repeating -group- 
statement,  denoted  by  RGROUP.  The  repeating -group-statement  contains 
the  name  of  the  repeating  group  (up  to  eight  characters)  and  an  optional 
parent  name.  The  parent  name  must  be  that  of  another  repeating  group 
(arrays  cannot  be  parents  of  repeating  groups).  If  the  parent  specifi- 
cation is  missing,  the  repeating  group  belongs  to  the  basic  data  set. 
Following  the  repeating-group-statement  is  a mandatory  field-definition- 
block.  A repeating  group  must  have  at  least  one  field  defined  for  it. 

The  end-repeating-group  statement  terminates  a repeating  group 
definition  and  is  denoted  by  ERGROUP. 

Only  hierarchical  structures  are  allowed  in  records  and  therefore 
an  aggregate  can  have  at  most  one  parent.  Also,  an  aggregate  cannot 
directly  or  indirectly  (through  other  aggregates)  be  its  own  parent. 


I 


45 


1 


Report  76-C-0899-1 


1 

) 


ADAPT  I TRANSFORMATION  DEFINITION  LANGUAGE 

Introduction 

The  Transformation  Definition  Language  (TDL)  provides  the  ADAPT  I 
superuser  with  a mechanism  to  input  host  file-specific  information 
required  to  generate  file  transformation  dictionaries.  Each  file 
accessible  under  ADAPT  I must  be  defined  twice:  the  UDL  interpretation 
of  the  file  must  be  supplied  via  the  Data  Definition  Language  (DDL)  and 
the  transformation- specific  information  must  be  supplied  via  TDL. 
Although  files  do  not  actueilly  exist  under  ADAPT  I (i.  e.  , there  is  no 
local  data  base  manager),  information  such  as  the  logical  file  organi- 
zation, local  and  target- system  nomenclature  and  file  data  positioning 
must  be  made  known  to  ADAPT  I via  DDL  and  TDL  in  order  to  generate 
the  appropriate  language  trainsformations.  It  is  interesting  to  note  that 
a local  file  capability  as  envisioned  for  later  ADAPT  phases  requires 
only  the  DDL  definition,  since  the  file  is  created  and  manipulated  locally. 

The  data  dictionary  definition  for  a file  must  exist  before  the  trans- 
formation specific  information  can  be  processed.  Basically,  the  trans- 
formation dictionary  stored  for  a file  contains: 

a.  File  name  as  known  on  host 

b.  Data  base  (host  file  resides  on) 

c.  Number  of  characters  transmitted  per  record  in  a character 
position  dependent  file  (if  applicable) 

d.  "Key"  field  (if  applicable) 

e.  Aggregate  names  as  known  on  host 

f.  Field  names  as  known  on  host 

1)  Position  field  description  (if  applicable) 

2)  Number  of  occurrences  (if  applicable) 
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: 

<tranfile 

<tranfile  - statement> 
< t r aniile  - cl  au  s e> 


Syntax 

<tranfile-statement>  ETRAN;  | 
<tranfile-statement>  <tranfile-block>  ETRAN; 

TRANFILE  <tranfile-clause>  <file-definition> ; 

<file-name>  j <file-name>  (<character- 
constant> ) 


<file-definition> 

<database -clause> 
<pos-clause> 


<database-clause>  | <database-clause>  <pos- 
clause>  I <database-clause>  <key-clause>  J 
<databa3e-clause>  <pos-clause>  <key-clause> 

DATABASE  (<database-id> ) 

POSITION  (<integer>) 


<key-clause> 


KEY  (<field-nam^) 


<tranfile-bloclo>  = <tran-field-state>  <tranfile -blocks  | 

<traLn-agg-state>  <tranfile-bloc]^  | 
<tran-field-state>  | <tran-agg-state> 


<tran-agg-  state> 
<tran-field-  state> 

<field-clause> 

<field-pos-clause> 

<database-id> 

<tran-array-state> 

<tran-rg-state> 


<tran-array-state>  i <tran-rg-state> 

FIELD  <field-clause>  <field-pos-clause>;  ( 
FIELD  <field-clause>; 

<field -name>  (<character-constant> ) 

1 <field-naine>  {<character-constant>, 
<character-constant> ) | <field-name> 

POS  (<integer>)  | POS  {<integer>,  <integer>) 

RYE  TIP  1 DIAOLS  | SOLIS  1 ISSPIC 

ARRAY  <array-name>  (<character-constant>); 

RGROUP  <repeating-group-name>  (<character- 
constant> ); 


I 

Semantics  ^ 


As  with  the  Data  Definition  Language,  the  foregoing  syntax  shows  the 
TDL  transformation  constructs  as  a total  definitional  block.  In  actuality, 
the  tranfile  is  a set  of  ordered  TDL  statements,  initialized  by  the  tranfile- 
statement  and  terminated  by  the  end-tranfile- statement. 
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The  tranfile  statement,  designated  by  TRANFIL.E,  consists  of  1) 
the  file-name  as  recognized  by  the  target  host  system,  2)  the  host  data- 
base where  the  file  resides,  3)  the  number  of  characters  transmitted 
per  record  and,  4)  the  "key"  field.  The  specified  file-name  is  the  UDL 
file-name  associated  (via  DDL)  with  a particular  file  structure  and  set 
of  data  dictionary  files.  If  the  file  is  known  by  a different  name  by  the 
target  system,  that  name  follows  in  the  form  of  a character-constant. 

The  statement  also  contains  a mandatory  database  identifier  and  optional 
maximum  record  size  specifier  and  key  field -name.  The  database 
identifier,  denoted  by  DATABASE,  indicates  the  target  host  system 
where  the  file  actually  resides.  The  number  of  characters  transmitted 
per  record  in  a character-position  dependent  file  is  input  as  an  integer 
after  the  keyword  POSITION.  Lastly,  the  key-clause  consists  of  the 
keyword  KEY  followed  by  the  name  of  the  key  field,  a previously  defined 
field  for  the  file.  A key  field,  when  applicable,  is  reqxiired  for  the 
interpretation  of  potential  duplicate  records  in  response  to  multiple 
queries,  amd  allows  the  output  translator  to  determine  when  the  output 
for  each  record  begins.  F ollowing  the  tranfile  statement,  an  optional 
group  of  statements,  referred  to  as  a tranfile -block,  may  appear.  The 
tranfile -block  consists  of  a series  of  transformation  aggregate  and  field 
definitions.  The  order  of  their  appearance  need  not  reflect  the  order  of 
their  input  for  the  file's  data  dictionary  files. 

When  an  aggregate  is  known  by  a name  other  than  the  locally  assigned 
UDL  aggregate  name,  the  target  host  system  name  is  specified  in  the 
tran-agg- state.  The  tran-agg- state  consists  of  three  parts;  1)  the 
keyword,  either  ARRAY  or  RGROUP,  which  designates  the  structural 
design  of  the  aggregate,  2)  the  name  (array-name  or  repeating-group- 
name)  which  is  the  UDL  name  for  the  aggregate  and,  3)  the  character- 
constant  which  is  the  name  by  which  the  target  host  system  recognizes  the 
aggregate. 
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M The  transformation  field  statement  has  several  constructs,  depending 

on  the  situation  and  the  required  information.  If  the  file  is  not  position 
<•  oriented,  the  local  UDL  field-name  is  followed  by  one  or  two  character- 

constants  containing  the  name(s)  by  which  the  field  is  known  by  the 
target  host  system.  If,  however,  the  file  is  position  dependent,  the 
tran- field- state  consists  of  a field-name,  optionally  followed  by  one  or 
two  character-constants  (target  host  system  name(s)),  and  the  position 
keyword  POS,  which,  in  turn,  is  followed  by  one  or  two  integers.  The 
first  integer  is  the  character  position,  i.  e.  where  the  field's  data  is 
stored  relative  to  the  beginning  of  the  record.  The  field  position  infor- 
mation of  each  field  within  a position-dependent  file  must  be  specified 
within  the  tranfile -block.  The  second  optional  integer  in  the  field-pos- 
clause  indicates  the  number  of  occurrences  associated  with  the  field 
and  is  required  if  the  field  is  a multi-valued  field. 

«• 

A tranfile  definition  is  terminated  by  an  end-tranfile  statement,  ETRAN. 
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CROSS  REFERENCE  FOR  ADAPT  I ERROR 
DIAGNOSTICS  AND  MESSAGES 


This  section  provides  a listing  of  all  error  diagnostics  or  messages 


produced  by  ADAPT  I statements  and  commands.  For  each  diagnostic 
the  following  information  is  given:  the  reference  number,  the  text,  the 
probable  cause  of  the  error,  the  action  to  be  taken  if  any,  and  a list  of 
ADAPT  statements  and  commands  which  produce  the  diagnostic /message. 


ADAPT  ERROR  1 

F rom: 

Cause: 

Action: 


ILLEGAL  FIELD  DESCRIPTION  FOR 
FIELD  (DDL) 

The  size  of  the  field  which  you  are  defining  via 
DDL  is  too  large. 

Retype  the  statement  with  a smaller  field  size. 


ADAPT  ERROR  2 PARENT  OF  REPEATING  GROUP  CANNOT 

BE  AN  ARRAY 


F rom: 
Cause: 

Action: 


ESCHEMA  (DDL) 

The  repeating  group  which  you  are  defining  via 
DDL  cannot  have  an  array  for  a parent. 

Review  the  file's  structure  and  determine  the 
correct  parent  of  the  repeating  group. 


ADAPT  ERROR  3 DUPLICATE  NAME 


F rom: 
Cause; 

Action: 


RGROUP,  ARRAY,  and  FIELD  (DDL) 

Field  and  aggregate  names  must  be  unique  for 
a given  file's  data  definition. 

Retype  the  statement  using  a unique  name. 


ADAPT  ERROR  4 INVALID  ATTRIBUTES  (NKEY  AND  INV)  FOR 

P I^u  XjD  ^ 


From: 

Cause; 

Action: 


FIELD  (DDL) 

A field  cannot  be  assigned  simultaneously  the 
attributes  invisible  (INV)  and  non-keyed  (NKEY). 
Review  the  attributes  of  the  field  and  adjust  the 
field  statement  accordingly. 
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ADAPT  ERROR  5 ATTRIBUTES  OF  FIELD  ***  DO  NOT  ALLOW 

VARIABLE  LENGTH 


F rom; 
Cause: 


Action: 


FIELD  (DDL) 

A field's  data  cannot  be  variable  in  length  if  the 
field  is  visible  and  multivalued.  In  the  following 
situations,  a variable  length  attribute  is  valid: 

a.  Field  is  invisible  and  multivalued. 

b.  Field  is  single-valued. 

First  review  the  characteristics  of  the  field  and 
then  adjust  the  field  statement. 


ADAPT  ERROR  6 TOO  MANY  FIELDS 


F rom: 
Cause: 

Action: 


FIELD  (DDL) 

You  have  exceeded  the  maximum  number  of 
fields  that  can  be  assigned  to  a file. 

Review  the  file  structure  and  act  accordingly 
by  removing  the  least  important  fields. 


ADAPT  ERROR  7 TOO  MAJSTY  AGGREGATES 


F rom: 
Cause: 

Action: 


ARRAY,  RGROUP  (DDL) 

You  have  exceeded  the  maximum  number  of 
aggregates  that  can  be  defined  for  a file. 
Review  the  file  structure  and  act  accordingly 
by  removing  the  least  important  aggregates. 


ADAPT  ERROR  8 UNEXPECTED  END-AGGREGATE  STATEMENT 


F r im: 
Cause: 


Action: 


ERGROUP,  EARRAY  (DDL) 

An  EARRAY  or  an  ERGROUP  statement  is  mis- 
placed. A properly  used  end-aggregate-state- 
ment should  appear  after  either  an  array  or  a 
repeating  group  definition. 

Remove  the  statement  from  the  present  sequence 
of  statements. 
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ADAPT  ERROR  9 


END -AGGREGATE  STATEMENT  DOES  NOT 
MATCH  AGGREGATE  STATEMENT 


F rom: 
Cause; 


Action: 


EARRAY,  ERGROUP  (DDL) 

An  EARRAY  statement  terminates  the  definition 
of  an  array.  An  ERGROUP  statement  terminates 
the  definition  of  a repeating  group. 

Choose  the  correct  end-aggregate  statement. 


ADAPT  ERROR  10 


F rom; 
Cause; 


Action: 


AGGREGATE  HAS  NO  FIELDS  DEFINED 
FOR  IT 

EARRAY,  ERGROUP  (DDL) 

At  least  one  field  must  be  defined  for  each 
aggregate.  This  rule  also  applies  to  the  basic 
data  set.  See  error  16. 

Define  at  least  one  field  for  the  aggregate. 


ADAPT  ERROR  11 


AGGREGATE  ***  IS  UNDEFINED 


F rom: 
Cause; 


Action: 


ADAPT  ERROR  12 

From;  ESCHEMA  (DDL) 

Cause;  The  specified  aggregate  is  involved  in  an  invalid 

circular  relationship;  the  given  aggregate  is  the 
parent  of  an  aggregate  which,  if  its  parent- son 
link  is  followed,  is  essentially  the  parent  of  the 
given  aggregate. 

Action:  1.  Review  the  file  structure  and  redefine  it 

accordingly. 

2.  Review  the  DDL  definition  of  the  file 

structure  and  correct  its  inconsistencies. 


ESCHEMA  (DDL) 

The  specified  aggregate  has  been  specified  as 
the  parent  of  another  aggregate  but  has  never 
been  formally  defined. 

Either  define  the  aggregate  or  reenter  the  state- 
ment which  specified  it  as  a parent. 

CIRCULAR  RELATIONSHIP  FOR  AGGREGATE  *** 
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ADAPT  ERROR  13 


NO  PARENT  AGGREGATE  FOR  FIELD  *** 


F rom: 
Cause: 


Action: 

ADAPT  ERROR  14 

From: 

Cause: 

Action: 

ADAPT  ERROR  15 


F rom: 
Cause: 


Action: 


FIELD  (DDL) 

The  specified  field  does  not  have  either  an  array 
or  repeating  group  with  which  it  is  to  be  asso- 
ciated. Once  the  basic  data  set  has  been  defined, 
a FIELD  statement  must  appear  between  an 
aggregate  statement  (ARRAY  or  RGROUP)  and  an 
end-aggregate  statement  (EARRAY  or  ERGROUP). 
The  FIELD  statement  is  to  be  reinitiated  or 
removed  from  the  file's  DDL  definition. 

ARRAY  ***  DIMENSION  IS  OUT  OF  RANGE 

ARRAY  (DDL) 

An  array's  dimension  cannot  be  less  than  one 
(1)  or  greater  than  four  hundred  (400). 

Reenter  the  array's  dimension  within  the 
allowed  range. 

SIZE  OF  FIELD  DATA  HAS  EXCEEDED  LIMIT 
FOR  AGGREGATE 

FIELD  (DDL) 

The  "naximum  size  for  an  aggregate  is  5000 
bytes.  An  aggregate's  size  is  equal  to  the  sum 
of  the  sizes  of  the  visible  fields  belonging  to 
the  aggregate. 

Check  the  file's  data  definition  for  accuracy, 
and  review  the  file  structure.  The  sizes  of 
the  fields  or  the  number  of  fields  defined  for 
the  aggregate  might  have  to  be  adjusted. 


ADAPT  ERROR  16 


NO  FIELDS  DEFINED  FOR  BASIC  DATA  SET 


F rom: 
Cause: 

Action: 


ESCHEMA,  ARRAY,  RGROUP  (DDL) 

At  least  one  field  must  be  defined  for  the  basic 
data  set. 

Define  a field  for  the  basic  data  set  before 
defining  any  aggregates. 
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ADAPT  ERROR  17 


From; 

Cause: 

Action; 

ADAPT  ERROR  18 

From; 

Cause: 

Action; 


ADAPT  ERROR  19 


F rom: 
Cause: 


Action: 


ADAPT  ERROR  2 1 


From: 

Cause; 


Action; 


TOO  MANY  LEVELS  OF  ARRAYS  FOR 
AGGREGATE  *** 

ARRAY  (DDL) 

An  array  may  have  at  most  two  levels  of  arrays 
to  which  it  is  subordinate. 

Redefine  the  file  structure. 

DUPLICATE  FILENAME  *** 

SCHEMA 

Each  file  defined  for  ADAPT  1 must  have  a 
unique  name. 

Perform  a VIEW  FILE  for  a listing  of  all  files 
for  which  data  definitions  exist.  Given  the 
established  file  names,  choose  a unique  file 
name. 

YOU  ARE  NOT  AN  ESTABLISHED  ADAPT  USER. 
CONTACT  THE  TASMASTER  TO  BECOME 
ESTABLISHED  AS  AN  ADAPT  USER 

ADAPT 

The  ADAPT  command  is  restricted  to  those 
users  who  are  authorized  to  use  ADAPT  by  the 
TASMASTER. 

Ask  the  TASMASTER  to  establish  you  as  an 
ADAPT  user. 

CANNOT  DELETE  SCHEMA/TRANFILE  AT  THIS 
TIME  BECAUSE  ADAPT  USERS  ARE  LOGGED  ON 

DELETE  SCHEMA,  DELETE  TRANFILE 
Due  to  interdependency  of  ADAPT  activities  on 
the  SCHEMA  and  TRANFILE  files,  neither  can 
be  deleted  until  all  other  users  are  logged  off  of 
ADAPT. 

Wait  until  all  other  users  are  logged  off  of  ADAPT. 
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•*  ADAPT  ERROR  22  THIS  STATEMENT /COMMAND  IS  RESTRICTED 

TO  THE  SUPERUSER 

SCHEMA,  TRANFILE,  DELETE  SCHEMA. 
DELETE  TRANFILE,  VIEW  TRANFILE, 
EXECUTE  SCHEMA,  EXECUTE  TRANFILE 
Statements  and  commands  which  maintain  the 
ADAPT  environment  are  restricted  to  the 
superuser. 

ADAPT  ERROR  23  TOO  MANY  FILES 

From;  ESCHEMA 

Cause:  You  have  exceeded  the  maximum  number  of 

target  system  files  allowed  for  ADAPT  I. 

ADAPT  ERROR  24  NESTED  EXECUTE  COMMANDS  ARE  NOT 

ALLOWED 

EXECUTE  SCHEMA,  EXECUTE  TRANFILE, 
EXECUTE 

An  execute  statement  cannot  appear  within  a 
file  which  has  been  named  within  a previous 
execute  statement  as  an  input  file. 

Remove  the  execute  statement  from  the  text 
file. 

ADAPT  ERROR  26  INVALID  DATABASE 

From;  TRANFILE 

Cause:  Valid  database  names  for  ADAPT  I are  RYETIP, 

DIAOLS,  SOLIS  and  ISSPIC. 

Action:  Retype  the  TRANFILE  statement. 

ADAPT  ERROR  27  NO  END -AGGREGATE  STATEMENT  FOR 

AGGREGATE 

RGROUP,  ARRAY,  ESCHEMA  (DDL) 

DDL  requires  that  the  data  definition  of  either 
an  array  or  repeating  group  is  terminated  by 
an  end- statement,  either  EARRAY  or  ERGROUP. 
Insert  the  appropriate  end  statement  after  the 
definition  of  each  aggregate. 


From: 

Cause: 


Action; 


F rom; 
Cause: 

Action: 


F rom: 


Cause: 
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ADAPT  ERROR  28  UNEXPECTED  EOF  IN  A SCHEMA  OR  TRANFILE 

DEFINITION 

From:  N/A 

Cause:  The  input  from  an  execute  file  has  terminated 

before  either  an  ESCHEMA  or  ETRAN  state- 
ment has  been  processed. 

Action:  Add  the  appropriate  end- statement  to  the  end 

of  the  text  file. 

ADAPT  ERROR  29  DATA  INCONSISTENCY  IN  TRANSACTION  COUNTS 

From:  DISPLAY,  SAVE 

Cause:  Error  29  is  an  internal  ADAPT  error. 

Action:  Please  take  notes  recreating  the  series  of 

events  leading  to  the  error  and  submit  your 
notes  to  the  TASMASTER. 

ADAPT  ERROR  30  CANNOT  RECOGNIZE  THE  TARGET  SYSTEM 

DATA.  THESE  RECORDS  CANNOT  BE 
PROCESSED. 

From:  VIEW  TRANS 

Cause:  The  process  which  scans  the  target  system 

records  does  not  recognize  the  contents  of 
the  record. 

Action:  Notify  the  TASMASTER. 

ADAPT  ERROR  3 1 TAG  IS  INVALID 

From:  FIND,  SAVE,  DISPLAY 

Cause:  The  tag  specified  after  the  keyword  SOURCE  is 

not  a valid  label  name.  The  tag  has  not  been  a 
label  of  one  of  your  previous  FIND  statements. 

Action:  List  the  current  labels  via  the  VIEW  LABEL 

command. 

ADAPT  ERROR  32  LIST  NAME  ***  IS  INVALID 

From:  DISPLAY,  DELETE  LIST 

Cause:  The  specified  list  name  is  not  found  in  the 

ADAPT  files. 

Action:  Perform  a VIEW  LIST  for  a display  of  your 

current  list  names. 
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ADAPT  ERROR  33  THIS  TRANSACTION  IS  NOT  COMPLETED 


From: 

Cause: 

Action; 


VIEW  TRANS 

The  transaction  which  you  are  attempting  to 
view  is  not  completed  and  cannot  be  viewed. 

Wait  until  the  transaction  is  completed.  Perform 
a VIEW  TRANS  to  output  the  status  of  your 
transactions. 


ADAPT  ERROR  34  FILE  NAME  IS  INVALID 


F rom: 
Cause: 
Action: 


OPEN,  CLOSE,  FIND,  VIEW  SCHEMA,  VIEW 
TRANFILE 

Tae  data  definition  for  the  specified  file  does 
not  exist. 

Perform  a VIEW  FILE  for  the  display  of  all 
current  ADAPT  files. 


ADAPT  ERROR  35  AGGREGATE  NAME  IS  INVALID 


F rom: 
Cause: 

Action: 


FIND,  ARRAY  (TDL),  RGROUP  (TDL) 

The  specified  aggregate  is  not  a defined  array 
or  repeating -group  for  the  file. 

Perform  a VIEW  SCHEMA  for  the  complete 
listing  of  the  particular  file's  data  structure. 


ADAPT  ERROR  36  FIELD  NAME  ***  IS  INVALID 


From: 

Cause: 

Action; 


FIND,  FIELD  (TDL) 

The  specified  field  is  not  a defined  field  for  the 
file. 

Perform  a VIEW  SCHEMA  for  a complete 
listing  of  the  specific  file's  data  structure. 


ADAPT  ERROR  37  FIELD  ***  MUST  BE  VISIBLE  TO  BE  DISPLAYED 


From; 

Cause: 

Action: 


DISPLAY 

A field  which  is  assigned  the  attribute  of  invisible 
cannot  be  specified  in  a DISPLAY  statement. 
Reword  and  retype  the  DISPLAY  statement. 
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ADAPT  ERROR  38 


CANNOT  REFERENCE  DEPENDENT  TAG 


F rom: 
Cause: 


Action: 


FIND 

When  a label  of  a FIND  statement  is  used  as  a 
reference  tag  for  a second  FIND  statement,  the 
label  for  the  second  FIND  statement  is  a dependent 
label.  This  latter  label  cannot  be  used  as  a tag 
in  yet  another  FIND  statement.  This  woxild 
imply  a second  level  of  dependency  in  the  FIND 
statement. 

Reevaluate  the  FIND  statement  and  its  relation- 
ship with  previous  FIND  statements. 


ADAPT  ERROR  39 


CANNOT  REFERENCE  TAG  BECAUSE  IT  WILL 
BE  REPLACED  BY  A NEW  TAG 


F rom: 
Cause: 


Action: 


FIND 

The  most  current  labels  for  a user's  interrogations 
are  maintained  for  that  user.  Once  the  maximum 
number  of  labels  have  been  used,  the  oldest 
label  is  always  replaced  by  the  newest  label.  If 
the  FIND  statement  is  dependent  on  the  label 
about  to  be  deleted,  error  39  is  output  and  the 
processing  of  the  FIND  statement  is  terminated. 
Retype  the  FIND  statement  upon  which  the  re- 
jected FIND  statement  is  dependent.  Once  this 
statement  has  been  processed,  retype  the 
dependent  FIND  statement. 


ADAPT  ERROR  40 


DUPLICATE  LIST  OR  LABEL  NAME  - 


F rom: 
Cause: 


Action: 


SAVE,  FIND 

A list  name  or  a label  (tag)  must  be  a unique 
name,  differing  from  a user's  current  list  of 
label  and  list  names. 

Retype  the  statement  with  a unique  list  name  or 
label.  Perform  a VIEW  LIST  and/or  VIEW 
LABEL  for  a complete  display  of  your  current 
listnames  or  labels. 
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ADAPT  ERROR  41 

F rom; 

Cause: 

Action: 


ADAPT  ERROR  42 


From: 

Cause: 


Action: 


ADAPT  ERROR  43 

F rom: 

Cause: 


Action: 


ADAPT  ERROR  44 

From: 

Cause: 

Action: 


FIELD  ***  MUST  BE  KEYED  TO  BE  USED  IN 
AN  INDEPENDENT  FIND  STATEMENT 

FIND 

An  independent  FIND  statement  requires  all 
specified  fields  to  be  keyed. 

Retype  the  statement.  Create  two  FIND  state- 
ments: the  first  is  independent  and  the  second 
is  dependent  with  the  specified  field  in  this 
statement. 

FIELD  ***  MUST  BE  KEYED  OR  DEPENDENT 
TO  BE  USED  IN  A DEPENDENT  FIND 
STATEMENT 

FIND 

The  fields  in  a dependent  FIND  statement  must 
have  the  attributes  of  keyed  or  dependent.  Non- 
keyed  fields  cannot  be  used  in  FIND  statements. 
Retype  the  FIND  statement  omitting  the  field 
name  within  the  original  FIND  statement. 

INCORRECT  CONSTANT  TYPE  FOR  FIELD  *** 

FIND 

Three  data  types  exist  for  fields:  character, 
numeric  and  geographic.  The  constant  type 
which  is  being  specified  for  the  field  name  and 
operator  must  be  analagous  to  the  field's  data 
type. 

VIEW  SCHEMA  displays  a file's  structure 
including  each  field,  its  name,  data  type,  size 
and  attributes. 

AGGREGATE  MUST  BE  A REPEATING  GROUP 
FIND 

Aggregates  which  are  used  as  scope  qualifiers 
must  be  repeating  groups. 

Review  the  field's  structure  and  retype  the 
statement. 
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ADAPT  ERROR  45  FIELD  ***  MUST  BE  IN  THE  SCOPE  REPEATING 

GROUP 

FIND 

The  fields  specified  within  a repeating  group 
scope  qualifier  must  be  defined  for  that 
repeating  group. 

Review  the  file's  structure  via  the  VIEW  SCHEMA 
command  and  retype  the  statement. 

INVALID  SUBSCRIPT  FOR  FIELD 

FIND,  DISPLAY 

The  subscripts  for  a field  must  not  exceed  the 
maximum  size  (dimension)  assigned  to  the  array 
to  which  the  field  is  subordinate.  The  subscript 
to  the  farthest  right  corresponds  to  the  array 
which  is  the  direct  parent  of  the  field.  As  you 
proceed  left,  the  subscript  refers  to  the  array 
which  is  the  parent  of  the  array  whose  subscript 
is  to  its  right. 

Review  the  file  structure  via  VIEW  SCHEMA  to 
list  each  array  and  its  maximum  dimension 
and  those  fields  defined  for  each  array. 

ADAPT  ERROR  47  FIELD  HAS  TOO  MANY  SUBSCRIPTS 

From:  FIND 

Cause:  The  number  of  subscripts  in  a field's  dimension 

must  equal  the  number  of  levels  of  arrays  to 
which  the  field  is  subordinate. 

Action:  Review  the  file's  structure  via  VIEW  SCHEMA 

and  adjust  the  FIND  statement  accordingly. 

ADAPT  ERROR  48  A FIND  STATEMENT  MUST  HAVE  A LABEL 

From:  FIND 

Cause:  Each  FIND  statement  must  have  a label;  otherwise, 

the  FIND  statement  is  not  processed. 

Action:  Retype  the  statement  with  a label  at  the  beginning. 


From: 

Cause: 


Action: 


ADAPT  ERROR  46 

From: 

Cause: 


Action: 
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ADAPT  ERROR  49  FIELD  ***  HAS  TOO  FEW  SUBSCRIPTS 


From: 

Cause: 


Action: 


ADAPT  ERROR  50 


FIND 

The  number  of  subscripts  in  a field's  dimension 
must  equal  the  number  of  levels  of  arrays  to 
which  the  field  is  subordinate. 

Review  the  file's  structure  via  VIEW  SCHEMA  . 
and  adjust  the  FIND  statement  accordingly. 

FIELD  NAME  OR  AGGREGATE  NAME  ***  IS 
INVALID 


From: 

Cause: 

Action: 


ADAPT  ERROR  5 1 


From: 

Cause: 


Action: 


ADAPT  ERROR  52 


DISPLAY 

The  specified  name  is  neither  a field  nor  an 
aggregate  defined  for  the  file. 

Review  the  file's  structure  via  VIEW  SCHEMA 
and  retype  the  DISPLAY  statement  accordingly. 

FIELD  ***  MUST  HAVE  SUBSCRIPTS  IN  A FIND 
STATEMENT 

FIND 

The  parent  of  the  specified  field  is  an  array,  . 
implying  the  need  for  the  field  to  be  subscripted. 
A field  does  not  necessarily  have  to  be  sub- 
scripted for  DISPLAY  statements. 

Review  the  file's  structure  via  VIEW  SCHEMA 
and  adjust  the  FIND  statement  accordingly. 

TRANSACTION  NUMBER  ***  IS  INVALID 


From: 

Cause: 

Action: 


ADAPT  ERROR  53 


VIEW  TRANS 

The  transaction  number  you  typed  in  is  not 
assigned  to  any  of  your  current  queries/responses. 
Perform  a VIEW  TRANS  for  a complete  listing 
of  your  transactions  and  their  statuses.  The 
entire  three  digits  must  be  entered. 

TAG  OR  LISTNAME  ***  IS  INVALID 


From: 

Cause: 

Action: 


DISPLAY 

The  specified  name  is  not  a current  label  or  list 
name  in  your  ADAPT  files. 

VIEW  LIST  and  VIEW  LABEL  give  you  a current 
listing  of  valid  list  and  label  names. 
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ADAPT  ERROR  54  USER  INPUT  FILE  ***  IS  INVALID 


From: 

Cause: 

Action: 


EXECUTE,  EXECUTE  SCHEMA,  EXECUTE 
TRANFILE 

The  input  file  as  specified  in  the  execute  state- 
ment is  not  an  existing  text  file. 

The  TAS  command  LIST  outputs  a listing  of  your 
text  files. 


ADAPT  ERROR  55  STATE]MENT  TOO  LONG 


From: 

Cause: 

Action: 


Any  overlength  statement. 

The  ADAPT  command /statement  exceeds  the 
maximum  statement  length. 

Review  the  format  of  the  c ommand  / statement 
and  retype. 


ADAPT  ERROR  56  INVALID  GEOGRAPHIC  EXPRESSION  FOR 

FIELD  *** 


F rom: 
Cause: 


FIND 

UDL  has  three  geographic  operators.  Each 
operator  accepts  only  specific  geographic 
expressions.  The  chart  below  indicates 
acceptable  relationships. 


Geographic 

Operator 

Geos 

'raphic  Expression 

Circle 

Polv 

Route 

Inside 

X 

X 

Outside 

X 

Along 

X 

Action:  Reword  your  FIND  statement,  matching  the 

correct  geographic  expression  with  the 
geographic  operator. 
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ADAPT  ERROR  57 


From: 

Cause: 


Action: 


ADAPT  ERROR  58 


F rom: 
Cause: 


Action: 

ADAPT  ERROR  59 


From; 

Cause: 


TOO  MANY/FEW  GEOGRAPHIC  CONSTANTS 
FOR  FIELD 

FIND 

The  geographic  expressions  POLY  and  ROUTE 
both  require  at  least  3 and  at  most  506  geographic 
constants. 

Review  the  geographic  expression  format  and 
retype  the  FIND  statement. 

RADIUS  OR  BAND  WIDTH  MUST  BE  OF  RANGE 
0.  1 to  2000  FOR  FIELD 

FIND 

The  band  width  for  the  ROUTE  geographic 
expression  and  the  radius  for  the  CIRCLE 
geographic  expression  must  be  a number  within 
the  range  of  0.  1 and  2000  inclusively. 

Reenter  the  statement  with  a correct  value. 

DEGREES,  MINUTES,  OR  SECONDS  IS  OUT  OF 
RANGE  FOR  A GEOGRAPHIC  CONSTANT  FOR 
FIELD  *** 

FIND 

Each  geographic  constant  contains  a latitude  and 
longitude  expression  in  that  order.  Both  latitude 
and  longitude  have  four  parts  in  their  full 
expressions:  degrees,  minutes,  seconds,  and 
direction  (N,S,  E,  W).  If  the  minute  and  seconds 
are  not  present,  the  default  values  are  0.  The 
chart  below  gives  the  allowable  numeric  ranges 
for  the  degrees,  minutes  and  seconds  for  both 
latitude  and  longitude. 
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Numeric  Value 


Low 

High 

latitude  degrees 

0 

90 

latitude  minutes 

0 

59 

latitude  seconds 

0 

59 

longitude  degrees 

0 

180 

longitude  minutes 

0 

59 

longitude  seconds 

0 

59 

Action:  Review  the  valid  formats  for  geographic  constants 

and  retype  the  FIND  statement. 

ADAPT  ERROR  60  WRG,  ORG  OPERATORS  REQUIRE  NUMBERS  TO 

BE  IN  INCREASING  NUMERIC  ORDER 

From:  FIND 

Cause:  The  operators  WRG  (within  range)  and  ORG  (out- 

of-range)  require  two  numeric  expressions  where 
the  first  number  must  be  less  than  the  second 
number. 

Action:  Reverse  the  two  numbers. 

ADAPT  ERROR  61  INVALID  NUMBER  OF  SCHEMA/TRANFILE 

STATEMENTS 

From:  TRANFILE,  SCHEMA 

Cause:  For  each  SCHEMA/TRANFILE  definition  at  most 

one  SCHEMA/TRANFILE  statement  may  appear 
within  the  definition.  The  presence  of  another 
such  statement  nullifies  the  definition. 

Action:  Remove  the  statement. 
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ADAPT  ERROR  62 

F rom: 

Cause: 


Action: 


ADAPT  ERROR  63 

F rom: 

Cause: 

Action: 

ADAPT  ERROR  64 

F rom: 

Cause: 

Action: 

ADAPT  ERROR  65 

F rom: 

Cause: 


Action: 


TOO  MANY  UNIQUE  BOOLEAN  VARIABLES 
FIND 

A FIND  statement  may  possess  at  most  eight  (8) 
unique  variables  where  a variable  is  defined  to 
consist  of  three  parts.  The  first  part  is  a field 
name,  the  second  part  is  the  operator,  and  the 
last  part  is  the  expression  (numeric,  geographic, 
or  character);  e.  g.  , if  two  variables  have  identi- 
cal field  names  and  operators  but  the  expressions 
differ,  the  variables  are  counted  as  two  (2)  unique 
variables. 

Reduce  the  number  of  unique  variables  in  your 
FIND  statement,  or  retype  the  FIND  statement 
as  two  statements,  an  independent  and  a 
dependent  FIND  (if  possible). 

TOO  MANY  LISTS 

SAVE 

You  have  exceeded  the  maximum  number  of  lists 
allowed. 

Delete  an  old  list  which  is  no  longer  useful. 

TRANSFORMED  STATEMENT  TOO  LONG  FOR 
TARGET  SYSTEM 

FIND,  DISPLAY,  SAVE 

Each  target  system  has  a maximum  length  for  a 
statement  which  it  can  accept  and  process. 

Reduce  the  complexity  of  your  FIND  statement. 

TOO  MANY  RECORDS  REQUESTED  WITH  THIS 
STATEMENT 

FIND 

If  after  the  interrogation  (FIND)  statement  has 
been  logically  evaluated  and  it  has  been  determined 
that  you  are  actually  requesting  all  data  stored  in 
the  target  system  file,  this  error  is  output;  e.  g.  , 
LAB  FIND  IN  TESTFILE  VAR  GT  42  OR  NOT 
(VAR  GT  42);  is  actually  asking  for  all  records 
in  TESTFILE. 

Evaluate  your  statement  and  pinpoint  the  problem. 
Reword  the  FIND  statement,  ensuring  that  you  are 
requesting  a subset  of  the  file. 
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ADAPT  ERROR  66  CANNOT  DELETE  LIST  ***.  IT  HAS  NOT  BEEN 

DELIVERED. 

From:  DELETE  LIST 

Cause:  A response  to  a query  must  be  displayed  (i.  e., 

delivered)  before  the  associated  list  name  can 
be  deleted. 

Action:  Display  the  list's  data  and  then  delete  it. 

ADAPT  ERROR  67  CONSTANT  IS  INCORRECTLY  FORMATTED 

F rom:  Any  statement 

Cause:  The  construction  of  a constant  is  incorrect. 

Action:  Study  the  statement's  valid  format  and  valid 

constant /expression  formats. 

ADAPT  ERROR  69  NO  RECORDS  WOULD  BE  R.EO.UESTED  WITH 

THIS  FIND  STATEMENT 

From:  FIND 

Cause:  This  error  message  corresponds  closely  with 

error  65.  Having  logically  evaluated  the 
interrogation  FIND  statement  it  is  determined 
that  the  user  is  not  requesting  any  data. 

Example: 

LABEL  FIND  IN  TESTFILE  VAR  GT  42  AND  NOT 
(VAR  GT  42) 

Since  no  record  could  possibly  contain  a value  of 
VAR  which  is  both  greater  and  not  greater  than  42 
simultaneously,  the  user  is  not  requesting  any 
data. 

Action:  Analyze  your  data  and  locate  the  error.  Now 

retype  your  FIND  statement. 
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ADAPT  ERROR  70 


F rom: 
Cause: 


ADAPT  ERROR  73 

F rom: 

Cause: 


Action: 


ADAPT  ERROR  75 


TOO  MANY  CHARACTERS  (FOR  NAME  OR 
CONSTANT)  FOR  FIELD 

Any  statement 

One  of  the  following  three  reasons  caused  this 
error:  (1)  In  a FIND  statement,  the  character 
constant  contains  more  characters  than  the  field 
size  allows  as  defined  via  DDL.  The  field's  size 
limits  the  number  of  characters  upon  which  a 
search  map  can  be  attempted.  (2)  In  a TRANFILE 
statement  the  number  of  characters  in  the  file's 
name  cannot  exceed  10  characters.  (3)  The  maxi- 
mum number  of  characters  per  name  is  8;  per 
character  constant  is  200;  per  number  is  12. 

TRANSACTION  FOR  LIST  IS  NOT  COMPLETE 
VIEW  TRANS 

Before  the  response  to  an  interrogation  can  be 
perused  by  a user,  the  transaction  between  the 
target  system  and  ADAPT  must  be  completely 
finished. 

Wait.  The  VIEW  LIST  command  provides  the 
means  to  list  the  status  of  your  lists. 

FILE  ***  NOT  OPEN 


From:  CLOSE,  FIND,  DISPLAY 

^^'^se:  One  of  the  following  three  reasons  caused  this 

error: 

1.  You  are  closing  a file  which  has  not  been 
opened. 

2.  You  are  interrogating  a file  which  has  not 
been  opened. 

3.  You  are  displaying  contents  of  an  unopened 
file  via  a DISPLAY  statement. 

Action:  Open  the  file. 


ADAPT  ERROR  76  FILE  ***  ALREADY  OPENED 


F rom: 
Cause: 
Action: 


OPEN 

The  file  has  previously  been  opened. 
None. 
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ADAPT  ERROR  77  TOO  MANY  OPEN  FILES 


F rom: 
Cause: 


Action: 


OPEN 

You  have  exceeded  the  maximum  number  of 
target  system  files  which  may  be  opened  at 
any  given  moment. 

Close  some  of  the  open  files. 


ADAPT  ERROR  78  TRANFILE  DATA  ALREADY  PRESENT  FOR 

FILE 


From: 

Cause: 


Action: 


TRANFILE 

The  superuser  can  redefine  a file's  TRANFILE 
definition  only  after  he  has  deleted  the  TRANFILE 
data  via  the  DELETE  TRANFILE  statement. 

Delete  the  TRANFILE  definition  for  the  file. 


ADAPT  ERROR  79  INVALID  POSITION  VALUE  FOR  FIELD  *'•:=* 


F rom: 
Cause: 


Action: 


FIELD  (TDD 

The  position  value  for  a field  must  be  an  integer 
greater  than  0 and  less  than  the  total  number  of 
characters  in  the  file. 

Reevaluate  the  field's  position  in  the  file. 


ADAPT  ERROR  80  INVALID  OCCURRENCE  COUNT  FOR  FIELD  *** 


F rom: 
Cause: 


Action: 


FIELD  (TDL) 

A field  which  is  multivalued  has  an  occurrence 
coxint  which  must  be  an  integer  greater  than  0 
and  less  than  496. 

Analyze  the  number  of  occurrences  for  the  field 
and  retype  the  field  statement. 


ADAPT  ERROR  81  POSITION  DATA  NECESSARY  FOR  FIELD 


From: 

Cause: 


Action: 


FIELD  (TDL) 

Each  field  in  a position-type  file  must  have  a 
position  value  associated  with  it.  This  error  is 
output  when  the  position  data  is  missing. 
Determine  the  field's  position  value. 
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ADAPT  ERROR  82 


LOCAL  DATA  BASE  MANAGER  NOT 
IMPLEMENTED  YET 


F rom: 
Cause: 
Action: 


DDL 

Self  - explanat  o r y. 
None. 


ADAPT  ERROR  83 


FIELD  ***  IS  NOT  MULTI-VALUED 


From: 

Cause: 


Action: 


FIELD  (TDD 

Those  fields  defined  to  be  multivalued  in  the 
field's  data  definition  must  be  assigned  an 
occurrence  count  in  the  file's  TRANFILE 
definition  for  position-type  files.  Only  such 
fields  may  have  occurrence  counts. 

Do  not  assign  the  indicated  field  an  occurrence 
count. 


ADAPT  ERROR  84 


OCCURRENCE  COUNT  NECESSARY  FOR 
FIELD 


F rom: 
Cause: 


Action: 


FIELD  (TDL) 

Those  fields  specified  as  multivalued  in  the 
field's  data  definition  must  be  assigned  an 
occurrence  count  in  the  file's  TRANFILE 
definition  for  position-type  files. 

Assign  an  occurrence  count  to  the  indicated 
field. 


ADAPT  ERROR  85 


FIELD  ***  POSITION  DATA  INVALID  FOR 
THIS  FILE 


From: 

Cause: 


Action: 


FIELD  (TDL) 

The  file  is  not  a position  file;  therefore  the  fields 
within  the  file  should  not  be  assigned  a position 
value. 

Either  remove  all  position  values  from  fields  in 
this  file's  TRANFILE  definition  or  specify  that 
the  file  is  position  oriented  in  the  TRANFILE 
statement  for  this  definition. 
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ADAPT  ERROR  86  ***  HAS  BEEN  PREVIOUSLY  DEFINED 


From: 

Cause: 

Action: 


FIELD,  ARRAY,  RGROUP  (TDL) 

Either  a field  or  aggregate  has  already  been 
defined  within  the  TRANFILE's  definition. 
Remove  duplicate  definitions. 


ADAPT  ERROR  87  DISPLAY  LIST  MUST  INCLUDE  AN  ELEMENT 

NAME 


F rom: 
Cause: 


Action: 


ADAPT  ERROR  88 


DISPLAY 

The  UDL  DISPLAY  statement  must  have  at  least 
one  element  in  the  display  list.  This  implies  that 
a display  list  must  consist  of  more  than  character 
constant  strings. 

Study  the  format  of  the  DISPLAY  statement  and 
retype  the  statement. 

TRANFILE  DATA  DOES  NOT  EXIST  FOR  FILE  *** 


F rom: 
Cause: 

Action: 


OPEN 

A file  cannot  be  opened  until  both  the  data  defi- 
nition and  the  TRANFILE  definition  exist. 
Inform  the  superuser  of  the  missing  TRANFILE 
definition  for  the  indicated  file. 


ADAPT  ERROR  91  TOO  MANY  LOGICAL  TRANSACTIONS 


From: 

Cause: 

Action: 


DISPLAY,  SAVE 

You  have  exceeded  the  maximum  number  of 
transactions. 

Perform  a VIEW  TRANS  in  order  to  determine 
which  previous  transactions  should  be  eliminated. 
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ADAPT  ERROR  93  LOGICAL  EXPRESSION  WITHIN  SCOPE 

EXPRESSION  HAS  AN  ERROR 

From:  FIND 

Cause:  The  selection  criteria  of  a scoped  expression 

cannot  ask  for  all  or  for  none  of  the  scoped  data. 
Errors  69  and  65  are  closely  related  to  this 
problem. 

Example : 

Scope  expression  which  logically  asks  for  all  data: 

RNAME  (FLD  EQ  5 OR  NOT  (FLD  EQ  5)  ) 

Scope  expression  which  logically  requests 
nothing: 

RNAME  (FLD  EQ  5 AND  NOT  (FLD  EQ  5)  ) 

Action:  Analyze  the  logical  expressions  in  the  scope 

expression  and  rewrite  the  statement. 

ADAPT  ERROR  98  YOU  MUST  USE  SEPARATE  EXECUTE 

COMMANDS  FOR  SCHEMA/TRANFILE 

From:  SCHEMA.  TRANFILE 

Cause:  The  file  specified  in  an  EXECUTE  statement 

must  contain  only  UDL  statements,  not  DDL  or 
TDL  statements. 

Action:  Use  an  EXECUTE  SCHEMA  or  EXECUTE 

TRANFILE  statement  to  process  a schema  or 
tranfile  definition  which  is  stored  in  a file. 

ADAPT  ERROR  100  REFERENCED  FIND  STATEMENT  HAS  AN 

INVALID  HIT  COUNT 

From:  DISPLAY  (Interactive  only) 

Cause:  You  are  trying  to  display  a statement  with  either 

a hit  count  of  zero  or  a hit  count  greater  than 
fifty. 

Action:  Redefine  the  FIND  statement  and  resubmit  your 

query. 

ADAPT  ERROR  102  INTERACTIVE  HOST  DATA  CANNOT  BE  SAVED 
From:  SAVE  (Interactive  only) 

Cause:  The  results  of  an  interactive  session  cannot  be 

saved  for  later  perusing. 

Action:  None. 
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ADAPT  ERROR 

From: 

Cause: 


Action: 


116  INVALID  POSITION  VALUE 
TRANFILE 

The  TRANFILE  position  value  is  either  zero  or 
beyond  the  host  system's  maximum  position 
value. 

Keep  the  position  value  between  one  and  495, 
inclusively. 
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CROSS  REFERENCE  FOR  ADAPT  I MESSAGES 

A message  is  output  by  ADAPT  either  to  inform  the  user  of  the 
status  of  the  system,  the  result  of  his  statement /command,  or  to 
instruct  the  user  of  his  next  action.  The  message  text  and  a list  of 
the  ADAPT  statements  and  commands  which  produce  the  message  are 
given  for  each  message;  however,  since  most  messages  are  self> 
explanatory,  the  cause  of  the  message  and  any  action  to  be  taken  is 
given  only  if  they  are  necessary.  For  your  convenience,  the  messages 
have  been  cdphabetized. 


H 
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COMMAND  COMPLETED 

From;  QUIT 

FILE  ***  HAS  BEEN  OPENED 
From:  OPEN 

list  ***  HAS  BEEN  DELETED 

From:  DELETE  LIST 

NO  HIT  COUNT  FOR  A BATCH  TRANSACTION 

FIND  (Batch  only) 

A FIND  statement  for  a batch  file  is  not  actually 
sent  to  the  appropriate  host  until  a SAVE  or 
DISPLAY  is  input  referencing  the  FIND. 
Therefore,  no  hit  count  is  known  for  the  query. 

NUMBER  OF  RECORDS  FOUND  NOT  SAME  AS  NUMBER  SPECIFIED  IN 

VIEW  TRANS 

Although  the  host  indicated  a specific  number  of 
records  which  satisfied  the  query,  only  a subset 
was  actually  transmitted.  This  is  conceivably 
due  to  the  host  truncating  an  oversized  output. 
Resubmit  the  query  with  a refined  set  of 
selection  criteria. 

NUMBER  OF  RECORDS  SELECTED  IS 

From:  FIND  (interactive),  VIEW  TRANS 


t 


[ OUTPUT 

E 

^ From: 

I Cause: 


Action: 


F rom: 
Cause: 


1 

J 

J.; 

J: 


]; 

J: 
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SORRY,  REFERENCED  FILE  NOT  AVAILABLE  FROM  THE  HOST  AT 
THIS  TIME 


F rom: 
Action: 


FIND  statement  to  SOLIS 
Reference  another  file  for  SOLIS. 


THERE  ARE  NO  FILE  DEFINED 


F rom: 
Cause: 


VIEW  FILE 

No  files  defined  for  ADAPT  at  this  time. 


TRANFILE  FOR  FILE  ***  HAS  BEEN  DELETED 


From; 


DELETE  TRANFILE 


TRANSACTION  DATA  FOR  THIS  LIST  WAS  NOT  FOUND,  THE  LIST  IS 
DELETED 


From:  DISPLAY 

Cause:  An  internal  problem  has  caused  this  error.  The 

list  has  accidently  been  deleted. 

Action:  Please  take  notes  on  the  sequence  of  statements 

which  lead  to  the  error  and  give  the  notes  to 
the  TASMASTER. 

TRANSACTION  NUMBER  FOR  THIS  BATCH  QUERY  IS 


F rom: 
Cause: 


DISPLAY,  SAVE 

Your  batch  query  has  been  assigned  a transaction 
number  which  is  used  in  VIEW  TRANS  statements 
to  monitor  the  status  of  and  to  view  the  response 
to  the  transaction. 


TRANSACTION  NUMBER  HAS  BEEN  DELETED 


From: 


VIEW  TRANS 


UNRECOGNIZED  ERROR  MESSAGE  AS  FOLLOWS: 


F rom; 
Cause: 


VIEW  TRANS 

The  target  host  system  has  sent  an  error  message 
which  ADAPT  is  not  capable  of  recognizing. 
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YOU  HAVE  AUTOMATICALLY  BEEN  REMOVED  FROM  THE  ADAPT 
SUB-SYSTEM 


Cause: 


An  internal  ADAPT  system  error  has  caused 
you  to  be  logged  off. 


YOU  HAVE  NO  BATCH  TRANSACTIONS 
From:  VIEW  TRANS 

YOU  HAVE  NO  LISTS  SAVED 


From:  VIEW  LIST 

YOU  HAVE  NO  LABELS 


J 


F rom: 


VIEW  LABEL 


YOUR  TRANSACTION  HAS  BEEN  EITHER  LOGGED  OUT  OR  LOST, 
PLEASE  RESEND  IT 


F rom: 
Action: 


VIEW  TRANS 

Resubmit  the  original  query. 


■ TO  GET  THE  NEXT  SCREEN,  HIT  THE  <NEWLINE>  KEY- 


J 


F rom: 


Any  statement  which  causes  output  to  be  paged 
to  the  terminal  screen. 
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APPENDIX  A 

UNIFORM  DATA  LANGUAGE  (UDL) 

A.  1 INTRODUCTION 

This  section  provides  a specification  for  the  Uniform  Data  Lainguage 
(UDL).  The  information  which  follows  is  divided  into  three  basic 
groups: 

a.  Basic  definitions. 

b.  Data  structures. 

c.  UDL  statements. 

Basic  definitions  provides  descriptions  of  the  character  set,  the 
construction  of  names  and  labels,  and  the  syntax  and  semantics  of 
basic  expressions.  Data  structures  are  described  with  respect  to 
their  logical  structure,  designated  data  types,  and  assigned  data 
attributes.  All  UDL  statements  are  described  where  their  syntax 
and  semantics  are  provided  in  detail. 


A.  2 BASIC  DEFINITIONS 

This  paragraph  presents  the  fundamental  definitions  for  the  UDL.  Included 
are  the  character  set,  data  name,  and  label  definitions,  and  descriptions 
of  the  data  constants  and  fundamental  expressions.  These  definitions 
and  their  syntax,  as  well  as  semantics,  will  be  referenced  constantly 
throughout  the  remainder  of  the  UDL  description. 
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The  character  set  assumed  by  UDL  will  be  the  American  Standard  Code 
for  Information  Interchange  (ASCII).  Out  of  this  character  set,  the  follow- 
ing delimiters,  digits,  and  letters  are  valid  for  UDL  statement 
construction. 

A.  2.  1.  1 Syntax. 

<delimiter>  = + 1 - 1 / I * I @ 1 ( I ) 1 » I • I = I ^ I ?!  % I ; 1 ' I CR 
<digit>  =0lll2l3|4l5l6l7|8|9 

<letter>  = AlB|C|D|ElF|G(H[  I|JiKlL|M|N|0|P| 

Q|RlS|TlUlV|W[X|YiZ 

A,  2.  1.  2 Semantics.  The  meaning  of  each  of  the  delimiters  is  as  follows: 

+:  binary  add  operator;  unary  plus  operator. 

binary  subtract  operator;  unary  minus  operator. 

/:  division  operator;  declare  delimiter;  geographic  constant  delimiter 

multiply  operator, 
initieil  character  for  variable  name. 

(:  expression.  Use,  or  grammatical  enclosure  (initial). 

):  expression,  list,  or  grammatical  enclosure  (terminal). 

, : list  separator. 

. : decimal  point;  label  delimiter. 

= : assignment  statement  delimiter. 

A:  designates  a space. 

?:  mask  character  for  CONTAINS  operator. 

%:  denotes  geographic  constant. 

; : terminates  statements  and  commands  - t 

delimits  (initial  and  terminal)  character  constant. 

CR:  new  line. 

1 
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Decimal  digits  are  used  to  express  numeric  constants,  to  form  labels  and 
names  (except  as  the  first  character),  and  to  form  character  and  geo- 
graphic constants. 

A letter  may  be  any  letter  of  the  alphabet.  Letters  may  be  used  in  labels, 
names,  and  in  character  and  geographic  constants. 

A.  2.  Z Names  and  Labels 

Names  and  labels  are  UOL  identifiers  which  are  constructed  by  the  user. 
Following  are  the  syntax  and  semantics  of  UOL  names  and  labels. 

A.  2.  2.  1 Syntax. 

<name>  = <name>  <letter>  [ <name>  <digit>  | <letter> 

<label>  = <name>  • <label>  | <name> 

<tag>  = <label> 

A.  2.  2.  2 Semantics.  Names  can  consist  of  up  to  eight  characters,  where 
these  characters  must  be  either  letters  or  digits.  The  first  character 
must  be  a letter.  Names  are  used  to  identify  various  entities  in  a UDL 
procedure  or  statement  complex.  All  syntactically  correct  names  are 
V2did  constructs  in  UDL  except  for  those  occurring  in  the  reserved  word 
list  in  table  A-  1. 

Names  can  be  utilized  in  two  basic  ways:  pure  names  or  as  parts  of  other 
identifiers.  Pure  names  can  occur  as  a procedure  name,  a list  name,  or 
as  a data  base  structure  name  (i.  e.  , file-name,  field-name,  etc.  ). 

Names  can  also  be  used  to  form  labels  or  variable  names. 

Labels  are  user -defined  identifiers  that  are  located  in  the  front  of  UDL 
statements.  The  use  of  labels  is  optional.  Labels  that  are  referenced  in 
UDL  statements  are  called  tags.  The  presence  of  a period  (.  ) in  a label 
implies  a UDL  statement  level.  Statements  with  labels  without  a period  are 
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Table  A- 1.  UDL  Reserved  Word  List. 


ACTION 

DECLARE 

FIND 

LT 

POSITION 

TAB 

ADD 

DELETE 

FORMAT 

MAX 

PROCEDURE 

TABSET 

ALL 

DEP 

GE 

MODE 

PULL 

THEN 

ALONG 

DESCEND 

GEO 

MV 

PUT 

TO 

AND 

DISPLAY 

GOTO 

NKEY 

QUIT 

TRAILER 

ARRAY 

DO 

GT 

NOR 

REC 

TRANFILE 

AT 

E 

HEADER 

NOT 

RECORD 

TRANS 

ATT 

EARRAY 

HSP 

NUM 

REMOTE 

TREE 

BATCH 

ECHO 

IF 

NUMERIC 

REMOVE 

TRESET 

BY 

ELSE 

IN 

OCC 

RETURN 

USE 

CALL 

END 

INPUT 

OCCURRENCE 

RGROUP 

V 

CAT 

EPROC 

INSIDE 

OFF 

ROUTE 

VAL 

CHANGE 

EQ 

INTER 

ON 

RTYPE 

VALIDATE 

CHAR 

ERGROUP 

INV 

OPEN 

SAVE 

VALUE 

CIRCLE 

ESCHEMA 

KEY 

OR 

SCHEMA 

VERT 

CLEAR 

ETRAN 

LABEL 

ORG 

SKIP 

VIEW 

CLOSE 

EXECUTE 

LE 

OUTPUT 

SORT 

VIS 

CONTAINS 

EXIST 

LINE 

OUTSIDE 

SOURCE 

WORD 

CREATE 

EXIT 

LIST 

PAGE 

SPACE 

WRG 

CURRENT 

FIELD 

LOCAL 

POLY 

SV 

XOR 

DATABASE 

FILE 

LOCSC 

POS 

are  at  statement  level-0,  statements  with  one  period  in  their  labels  are 
at  statement  level- 1,  and  so  on.  Statements  without  labels  assume  the 
level  of  the  first  statement  with  a label  that  precedes  it.  The  rules 
governing  statement  levels  with  respect  to  the  data  manipulation 
statements  are  discussed  when  applicable  in  paragraph  A.  4.  5. 
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A.  2.  3 Data  Constants  i 


This  paragraph  specifies  the  syntax  and  semantics  for  all  legal  UDL  data 
constants.  UDL  recognizes  three  basic  data  constants:  character-constants, 
numeric-constants,  and  geographic-constants.  Refer  to  paragraph  A.  3.  2 
for  discussion  of  data  types. 


A.  2.  3. 1 Syntax. 


<data- constant  s> 

<character-constant> 

<characters> 

<nume  ric  - c ons  tant> 

<f  ixe  d - point  - c ons  tant> 
<nume  ric  - c lau s e> 


<character-constant>  | <numeric-constant>  | 
<geographic-constant> 

'<characters>' 

<letter>  <characters>  | <digit>  <characters>  | <delimiter> 
<characters>  | <letter>  1 <digit>  | <delimiter> 
<fixed-point-constant>  I <floating-point-constant> 

<sign>  <numeric-clause>  1 <numeric-clause> 

<digit>  <numeric -clause>  | <numeric-clause>  . 
<numeric-clause>  | <numeric-clause>  . | 
<numeric-clause>  | <digit> 


<sign>  = 

<floating-point-constant>  - 
<geographic-constant>  = 
<lat-term>  = 

<position-terml>  = 

<degreel>  = 

<min-sec>  = 

<min>  = 

<sec>  = 

<directionl>  = 

<long-term>  = 

<position-term2>  = 

<degree2>  = 

<direction2>  = 


+ I - 

<fixe d- point -c  on stant>  E <digit>  <digit> 
'36<lat  -te  rm>  / <long  - te  rm> 
<position-terml>  <dircctionl> 
<degreel>  A <min-scc>  | <degreel> 
<digit>  <digit>  | <digit> 

<min>  A <sec>  | <min> 

<degree 1> 

<degree 1> 

N I S 

<position-term2>  <direction2> 
<degree2>  A <min-sec>  j <degree2> 
<digit>  <degreel>  | <digit> 

E I W 
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A.  2.  3.  2 Semantics.  The  three  UDL  data  constants  are  legal  in  a 
multitude  of  UDL  statements.  For  UDL  data  structures,  character- 
constants  are  applicable  for  variable -length-text,  fixed-length-text,  and 
alphanumeric  data  types  (refer  to  paragraph  A.  3.  2).  Numeric-constants 
are  valid  in  data  structures  with  numeric  data  types  only,  and  geographic- 
constants  are  valid  in  data  structures  with  geographic  data  types  only, 

A.  2.  4 Expressions 

There  are  two  primary  expression  types  recognized  in  UDL:  boolean- 
expressions  and  n\imeric -expressions.  Numeric -expressions  are  divided 
into  two  kinds:  numeric  and  restricted  numeric.  In  addition  to  the 
normal  expressions  described  in  this  paragraph,  there  is  another  impor- 
tant expression-like  construct  recognized  in  UDL  Ccilled  selection- 
criteria.  Selection-criteria  is  described  in  paragraph  A.  4.  Following 
are  the  syntax  and  semantics  for  UDL  expressions. 


A.  2.  4.  1 Syntax. 
<expression> 

<boolean-  expre  s sion> 

<boolean-clause> 

<boolean-phrase> 

<log-op> 

<boolean-factor> 

<boolean-primary> 


= <boolean-expression>  | <numeric- 
expressiori>  | <restricted-num-exp> 

= <boolean-clause>  OR  <boolean- 
expressioh>  | <boolean-clause> 

= <boolean-phrase>  AND  <boolean- 
clause>  I <boolean-phrase> 

= <boolean-factor>  <log-op>  <boolean- 
phrase>  1 <boolean-factor> 

= XOR  1 NOR 

= NOT  <boolean-factor>  | <boolean- 
primary> 

= (<boolean-expression>  ) I <relational- 
term> 
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< relational  -te  rxn> 

<data-spec> 

<rel-op> 

<numeric  -expre  s sioxv> 

<char-clause> 

<nuine  ric  - opl> 

<nume  r i c - clau  s e> 

<nume  ric  - op2> 

<nuineric -phrase> 

<nume ric  - op3> 

<numeric  -primary> 
<nuiiieric  -term> 

<data-tern5> 

<field-term> 

< subscript -list  1> 

<subscript-list2> 

<subscript> 

<array-term> 

<repeating-group-term> 


= <data-8pec>  <rel-op>  <numeric- 
expression> 

= <£ield-term>  | <variable-term> 

= LT  I GT  I LE  i GE  I EQ 
= <char-clause>  CAT  <nuxneric- 
expressidn>  I <char-clause> 

= <numeric-clause>  <numeric-opl> 
<char-clause>  | <nume ric- clau se> 

= +I  - 

= <n\imeric-phrase>  <numeric-op2> 

<nume ric- clau se>  j <numeric-phra8e> 

= * I / 

= <numeric-op3>  <nuineric-phrase>  | 
<nuineric -primary> 

= +1  - 

= (<char-clause> ) | <numeric-terTn> 

= <field-term>  j <variable-terin>  [ 
<data-constant>  | <function> 

= <f ield -te rin>  | <array-term>  ] 

<repeating-group-terin>  | <variable-tenn> 
= <field-name>  (<subscript-listl>)  | 

<f  ield  -name> 

= <subscript>,  <subscript-list2>  | 
<sub8cript> 

= <subscript>,  <subscript>  | <subscript> 

= <numeric-expressiori> 

= <array-name> 

= <repeating-group-name>  (<numeric- 
expre3siori>)  | <repeating-group-name> 
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< variable  -te  rni> 

<field-name> 

<array-name> 
<repeating-group-name> 
<variable  -naine> 
<restricted-num-expression> 

<restricted-char-clause> 

< r e str  icte  d-nuiri-  cl> 

< r e st  rict  e d - num  - ph> 
<restricted-num-priin> 

<restricted-iium-terin> 

<function> 

<function-input-list> 

< function, - input  - par  ain> 

<restricted-function?' 

< rest  ricted- input -list> 

<restricted- input -param> 


= @ <variable-name> 

= <name> 

= <naine> 

= <name> 

= <name> 

= <restricted-char-clause>  CAT 
<restricted-nuin-expression>  j 
<restricted-char-clause> 

= <restricted-nuni-cl>  <nvinieric-opl> 

<restricted-char-clause>  1 <restricted- 
num-cl> 

= <restricted-nuin-ph>  <nuineric-op2> 
<restricted-num-cl>  I <restricted-nxiin- 
ph> 

= <n\mieric-op3>  <restricted-n\ini-ph>  | 
<restricted-num-priin> 

= (<restricted-char-clause> ) | <restricted 
num-term> 

= < variable -terin>  j <constant>  I 
<restricted-function> 

= <f\mction-name>  (< fimction- input -li st> ) 
i <function-name> 

= <function-input-param>,  <function- 
input-list>  1 <function- input -parain> 

= <field-terni>  \ <variable-term>  | <data- 
constant> 

= <function-name>  (<restricted-input- 
list>)  I <function-name> 

= <restricted-input-param>,  <restricted- 
input-list>  I <restricted-input-param> 

= <variable-terin>  | <data-constant> 


8. 
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A.  2.  4.  2 Semantics.  Boolean-expressions  are  legal  as  the  condition- 
clause  of  ein  IF  statement,  and  niimeric -expressions,  both  normal  and 
restricted,  are  valid  in  many  UDL  statements.  Table  A-2  lists  all  the 
UDL  statements  showing  legal  expression  occurrences. 

A.  2.4.  2.  1 Boolean-Expressions.  Boolean-expressions  may  utilize  four 
binary  boolean  operators  and  one  unary  operator  in  their  construction. 
Following  is  the  evaluation  of  these  five  boolean  operators. 

a.  OR  — boolean  "inclusive-or"  condition  (union). 

A OR  B 

0 0 0 

0 1 1 

1 1 0 

1 1 1 

b.  AND  — boolean  "and"  condition  (intersection). 

A AND  B 

0 0 0 

0 0 1 

1 0 0 

111 

c.  XOR  — boolean  "exclusive -or"  condition. 

A XOR  B 

0 0 0 

0 1 1 

1 1 0 

1 0 1 
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TABLE  A-2.  EXPRESSION  OCCURRENCES  IN  UDL  STATEMENTS. 


Statement 

Boolean 

Numeric 

Restricted 

Numeric 

ADD 

— 

— 

Yes 

Assignment 

— 

Yes 

Yes 

CALL 

— 

Yes 

Yes 

CHANGE 

— 

— 

Yes 

CLEAR 

— 

— 

— 

CREATE 

— 

— 

Yes 

DECLARE 

— 

— 

— 

DELETE 

— 

— 

Yes 

DISPLAY 

- 

Yes 

Yes 

DO 

- 

Yes 

Yes 

DO  OCCURRENCE 

— 

— 

- 

DO  RECORD 

— 

- 

— 

DO  value 

— 

— 

— 

FIND 

— 

- 

Yes 

FORMAT 

— 

Yes 

Yes 

GOTO 

— 

Yes 

Yes 

HEADER 

— 

Yes 

Yes 

IF 

Yes 

- 

- 

OFF 

— 

- 

- 

ON 

- 

— 

- 

PROCEDURE 

— 

— 

- 

PULL 

- 

— 

- ^ 

PUT 

— 

— 

— 

REMOVE 

— 

— 

- 

SORT 

— 

— 

- 

TABSET 

— 

Yes 

Yes 

TRAILER 

Yes 

Yes 
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d.  NOR  — boolean  "joint-denial"  condition  (not-or). 

A NOR  B 

0 1 0 

0 0 1 

1 0 0 

1 0 1 

e.  NOT  — boolean  "complement"  condition  (negation). 

NOT  A 

1 0 

0 1 

Boolean  operator  precedence  is  the  following: 

a.  NOT. 

b.  XOR,  NOR. 

c.  AND. 

d.  OR. 

The  boolean  operators  XOR  and  NOR  are  evaluated  "left-to-right.  " The  use 
of  parentheses  is  valid  in  boolean-expressions  where  they  force  precedence 
inside  their  scope.  Parentheses  may  be  nested  and,  if  so,  evaluation  pro- 
ceeds from  the  innermost  parenthesis  level  outwards.  Boolean  operator 
arguments,  termed  boolean-primary  in  the  syntax,  can  either  be  another 
boolean-expression  if  in  parentheses,  or  a relational-term.  Relational-terms 
are  formed  by  placing  relational  conditions  on  cither  field-terms  or  variable- 


terms. 
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Five  relational  operators  are  legal  in  UDL  boolean-expressions  where  they 
operate  as  follows: 

LT  — data -specification  less  than  nunaeric-expression. 

GT  — data-specification  greater  than  numeric-expression. 

LE  — data-specification  less  than  or  equal  to  numeric-expression. 

GE  — data-specification  greater  than  or  equal  to  numeric -express ion. 
EQ  — data-specification  equals  numeric-expression. 

In  boolean-expressions,  both  user-defined  variables  and  file  data  structures 
(fields)  are  valid  data-specification  designations  for  relational  conditions. 

A.  2.  4.  2.  2 Numeric-Expressions.  Five  binary  operators  and  two  unary 
operators  can  be  used  in  constructing  numeric-expressions.  Following  are 
the  definitions  of  these  operators: 

a.  Binary  operators : 

+ : arithmetic  addition. 

-:  arithmetic  subtraction. 

*:  arithmetic  multiplication. 

/:  arithmetic  division. 

CAT:  character  string  concatenation. 

b.  Unary  operators : 

+ : plus  sign. 

-:  minus  sign. 

Operator  precedence  is  as  follows: 

a.  +,  - (unary  operators). 

b.  / 

c.  +,  - 

d.  CAT 


88 


Report  76-C-0899-1 


The  CAT  operator  has  the  lowest  precedence  where  it  cannot  be  used  as  an 
argument  of  a numeric  operator  (see  syntax).  This  implies  that  conversion 
from  numeric  to  character  is  valid  but  not  the  reverse.  Figure  A- 1 specifies 
the  legal  operator /data  type  combinations  for  numeric-expressions. 

Parentheses  are  legal  in  numeric -expressions  where  they  force  operator 
precedence  within  their  scope. 

The  subscript-list  associated  with  a field  is  valid  only  for  fields  defined  for 
arrays.  Repeating  group  indexing  is  not  allowed  on  subordinate  fields.  Oc- 
currence indexing  is  legal  for  repeating  groups  where  the  data  set  level  of 
that  repeating  group  can  be  controlled  (i.  e.  , one  subscript).  Refer  to  para- 
graph A.  3.  1.  2 for  more  information. 

UDL  functions  are  not  defined  at  this  time.  Their  syntax,  however,  is  pro- 
vided such  that  their  inclusion  can  be  made  at  a later  time. 

Restricted-numeric-expressions  are  identical  to  numeric -express ions  except 
their  numeric-terms  cannot  contain  field-terms.  Restricted-numeric- 
expressions  are  utilized  in  UDL  update  statements  (refer  to  table  A-2). 


Data  Types 

Character 

Numeric 

Geographic 

Character 

CAT 

CAT 

CAT 

Numeric 

CAT 

CAT,  +, 

*1  / 

CAT 

Geographic 

CAT 

CAT 

CAT 

Figure  A-1.  Legal  Numeric  Operator /Data  Type  Combinations. 


DATA  DESIGN 
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This  paragraph  describes  the  data  structures,  data  types,  and  data  attributes 
recognized  in  UDL.  There  exist  five  primary  data  structures  in  UDL: 


a.  Field. 

b.  Aggregate. 

c.  Record. 

d.  File. 

e.  Data  base. 

Data  types  are  associated  with  the  lowest  level  data  structure,  the  field, 
where  three  basic  types  are  defined: 


a.  Character. 

b.  Numeric. 

c.  Geographic. 

Along  with  data  types,  access  attributes  are  also  associated  with  the  field, 
where  they  control  access  with  respect  to  interrogation,  display,  and  update. 

For  each  field  or  aggregate  defined,  its  logical  structure  is  represented  with 
special  symbology. 


The  remainder  of  this  paragraph  discusses  the  foregoing  in  detail. 

A.  3.  1 Data  Structures 

Five  primary  data  structures  are  recognized  in  UDL:  data  bases,  files, 
records,  aggregates,  and  fields.  The  most  important  structures  with  respect 
to  user  utilization  and  overall  UDL  design  considerations  are  fields  and  ag- 
gregates. These  two  structures  will  be  discussed  first. 
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A.  3.  1.  1 Fields.  Two  field  structures  are  recognized  in  UDL: 

a.  Single -valued  field. 

b.  Multivalued  field. 

The  two  fields  are  discussed  in  paragraphs  A.  3.  1.  1.  1 and  ^ 3.  1.  1.  2, 
where  their  logical  structure  and  rules  governing  their  access  witli  respect 
to  interrogation,  display,  and  update  are  described. 

A.  3.  1.  1.  1 Single -Valued  Field.  A single -valued  field  has  the  logical  struc- 
ture depicted  in  figure  A-2.  It  has  a name  with  which  is  associated  a single 
value  occurrence.  All  references  to  a single-valued  field  must  reference  its 
name.  The  value  associated  with  a single-valued  field  must  conform  to  the 
data-type  defined  for  that  field. 

A single-valued  field  can  be  interrogated  by  referencing  its  name  against 
some  relational  condition  where  a match  is  successful  depending  on  its 
single -valued  occurrence.  Single-valued  fields  may  have* their  single  value 
occurrence  changed  by  a CHANGE  statement.  They  cannot,  however,  be 
added  to  or  deleted  from  by  the  ADD  and  DELETE  statements,  which  are 
used  exclusively  with  multioccur ring  structures. 

A.  3.  1.  1.  2 Multivalued  Field.  A multivalued  field  has  the  logical  structure 
depicted  in  figure  A-3.  It  has  a name  with  which  is  associated  a set  of  value 


field-name 


value 


Figure  A-2.  Logical  Structure  of  a Single-Valued  Field. 


Figure  A-3.  Logical  Structure  of  a Multivalued  Field. 


occurrences.  All  references  to  a multivalued  field  must  reference  its  name. 
Each  value  occurrence  of  a multivalued  field  must  conform  to  the  data-type 
defined  for  that  field.  The  number  of  value  occurrences  that  can  be  contained 
in  a multivalued  field  is  arbitrary,  where  no  occurrences  or  many  occur- 
rences are  possible, 

A multivalued  field  can  be  interrogated  by  referencing  its  name  against  a 
relational  condition  where  a match  is  successful  depending  on  a value-by- 
value search  of  the  value  occurrence  set  contained  in  the  field.  Multivalued 
fields  may  have  a given  value  occurrence  changed  to  a new  value  by  the 
CHANGE  statement,  one  or  more  value  occurrences  deleted  by  the  DELETE 
statement,  or  one  or  more  value  occurrences  added  by  the  ADD  statement. 

If  a multivalued  field  is  displayed  where  it  is  not  under  the  control  of  a DO 
OCCURRENCE  or  DO  VALUE  loop,  all  values  are  displayed.  If  it  is  under 
the  control  of  a DO  OCCURRENCE  loop,  tliat  value  occurrence  currently 
pointed  to  by  the  loop  will  be  displayed.  If  the  multivalued  field  is  under  the 
control  of  a DO  VALUE  loop,  the  unique  value  which  is  currently  active  is 
displayed.  "Under  control"  means  that  the  multivalued  field  is  the  argument 
source  of  the  DO  OCCURRENCE  or  DO  VALUE  statement  (being  inside  the 
loop  is  not  sufficient). 
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A.  3.  1.  2 Aggregates.  Aggregates  are  a named  collection  of  fields  and/or 
other  aggregates.  This  named  collection  of  data  structures  can  occur  an 
arbitrary  number  of  times  within  a record.  One  occurrence  of  such  a col- 
lection is  called  a data  set.  Since  aggregates  may  contain  other  aggregates, 
complex  hierarchical  structures  can  be  formed  with  them.  A collection  of 
data  sets  belonging  to  the  same  aggregate  and  having  the  same  ancestral  oc- 
currence of  a parent  aggregate  is  called  an  aggregate  instance. 

In  most  cases,  an  aggregate  is  a structural  convenience  where  the  aggregate 
itself  cannot  be  referenced  specifically  for  the  reading  or  writing  of  data. 
There  exist  exceptions  to  this,  however,  where  aggregates  can  be  referenced 
as  a totality.  Generally  these  exceptions  deal  with  loop  control  of  aggregate 
occurrences  and  with  convenience  modes  in  data  display.  Table  A-3  illus- 
trates those  cases  where  aggregate  names  are  legal  in  UDL  statements. 

Aggregates  do  not  have  specific  data  types  or  data  attributes  associated  them. 
Since  an  aggregate  can  have  an  arbitrary  number  of  fields  defined  for  it,  it 
may  have  many  data  types  and  data  attributes.  Two  aggregate  data  struc- 
tures are  defined  in  UDL: 


a.  Array. 

b.  Repeating  group. 


Paragraphs  A.  3.  1.  2.  1 and  A.  3.  1.  2.  2 discuss  these  aggregates  in  detail. 

A.  3.  1.  2.  1 Array.  An  array  is  a named  multivalued  data  structure  which 
can  be  composed  of  any  number  of  fields  or  arrays.  An  array  has  tlic  logical 
structure  depicted  in  figure  A-4.  Repeating  groups  cannot  be  pai-t  of  an 
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TABLE  A-3.  AGGREGATE  NAME  OCCURRENCES  IN  UDL  STATEMENTS. 


Array 

1.  Display-item  in  DISPLAY,  HEADER,  and  TRAILER  (sub- 
scripting illegal). 

Repeating  Group 

1.  Scope-qualifier  in  selection- criteria  for  FIND,  DISPLAY, 
HEADER,  and  TRAILER  (subscripting  illegal). 

2.  Occurrence -qualifier  for  CHANGE,  ADD,  and  DELETE 
(subscripting  illegal), 

3.  Occurrence-control  for  DISPLAY,  HEADER,  TRAILER,  and 
DO  OCCURRENCE  (subscripting  optional). 

4.  Repeating  group  addition  for  CREATE  and  ADD  (subscript- 
ing illegal). 

5.  Occurrence -deletion  for  DELETE  (subscripting  optional). 

6.  Max- specification  for  DISPLAY,  HEADER,  TRAILER, 
FORMAT,  and  DO  (subscripting  illegal). 

array  definition.  At  least  one  field  must  be  defined  in  an  array.  An  arbi- 
trary number  of  occurrences  of  an  array  data  set  is  legal,  but  the  number  of 
occurrences  must  be  established  as  part  of  the  array's  definition.  There- 
fore, occurrences  cannot  be  added  or  deleted  by  using  the  ADD  or  DELETE 
statements. 

An  array  cannot  be  interrogated  as  a totality,  where  references  are  re- 
stricted to  actual  fields  defined  for  that  array.  For  each  array  defined  in  a 
record,  an  index  is  associated  with  it.  This  index  has  the  range  1 — n where 
n is  the  number  of  occurrences  defined  for  that  array.  All  references  to 
fields  defined  in  an  array  must  be  accompanied  by  this  index.  Since  arrays 


i - 


• • 

f 

army-name  1 

# • 

field-name  1 

array-name2 

field-namel 

array-name2 

! . . 

/ 

field- 

namez 

field- 

name2 

/ 

field- 

name2 

field- 

name2 

1 / 

1.1  / 

• • • 

1 , m / 

. . . 

n / 

n,l  / 

• • • 

n,m  / 

/ value 

/ value 

/ value 

/ value 

/ value 

/ value 

t 


I ••  Figure  A-4,  Logical  Structure  of  an  Array  (two  array  levels 

[ , . are  shown). 


can  be  nested,  other  implied  subscripts  are  also  required.  That  is,  if  a 
given  array  is  defined  under  two  other  arrays,  three  subscripts  must  be 
specified  in  its  field  references.  Array-name  references  are  legal  in  dis- 
play only  (refer  to  table  A-3)  where  an  entire  array  can  be  displayed. 


A.  3.  1.  2.  2 Repeating  Group.  A repeating  group  is  a named  multivalued 
x"  data  structure  which  can  be  composed  of  any  number  of  fields,  arrays,  or 
other  repeating  groups.  A repeating  group's  logical  structure  is  depicted  in 
figure  A- 5.  At  least  one  field  must  be  defined  in  a repeating  group.  An 
arbitrary  number  of  occurrences  of  a repeating  group  data  set  is  legal, 
where  occurrences  can  be  added  or  deleted  via  the  ADD  or  DELETE 
commands. 
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Since  repeating  groups  cannot  be  referenced  for  data  themselves,  only  the 
fields  defined  within  a repeating-group  structure  can  be  referenced  in  ex- 
pressions. Therefore,  in  order  to  transgress  through  the  occurrences  of  a 
given  repeating  group,  an  appropriate  DO  OCCURRENCE  loop  must  be 
established.  In  addition,  if  this  repeating  group  is  nested  in  other  repeating 
groups,  the  appropriate  number  of  DO  OCCURRENCE  loops  (nested)  must  be 
present.  If  less  than  the  required  number  of  loops  is  established  (the  ap- 
propriate number  of  loops  is  equal  to  the  number  of  nested  repeating  groups), 
the  ambiguity  will  be  eliminated  by  the  system  where  only  the  "left-most” 
occurrence  is  accessed  (as  is  the  case  for  referencing  mviltivalued  fields). 

In  order  to  illustrate  the  effect  of  the  DO  OCCURRENCE  statement  on  the 
repeating  group,  six  examples  of  varying  complexity  are  given  in  the  follow- 
ing. All  examples  utilize  the  single  record  data  structure  shown  in  figure 
A-6. 


Example  1: 

@A  = FI 
@B  = F2 
@C  = F3 


1— @A 
4— @B 
7— @C 


In  this  example,  a DO  OCCURRENCE  statement  is  not  used.  The  variables 
"@A,  " "@B,  " and  "@C"  are  assigned  a value  from  three  multivalued  fields 
FI,  F2,  and  F3.  Note  that  the  "left-most"  value  is  referenced  each  time. 

Example  2; 

DO  OCCURRENCE  RGl  END  {a) 


PASS-1 


PASS -2 


@A  = FI 
@B  = F2 
^C  = F3 


1 — @A  1 9— @A 


4— igB 
7— @C 


22— @B 
2 5— @C 


r 


L 
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In  this  example,  the  DO  OCCURRENCE  statement  will  loop  two  times,  once 
for  each  occurrence  of  repeating  group  RGl.  For  the  first  pass  through  the 
loop,  the  variables  are  assigned  the  "left-most"  value  of  the  first  occurrence 
of  RGl  for  the  fields  FI,  F2,  and  F3.  On  the  second  pass,  they  are  assigned 
the  "left-most-value"  of  the  second  RGl  occurrence. 


Example  3: 


DO  OCCURRENGE  RGl  END  (o) 


DO  OCCURRENCE  RG2  END  ( p ) 


PASS-1 

PASS -2 

PASS -3 

• 

II 

1— @A 

1 — @A 

1S-@A 

• • 

@B  = F2: 

4— @B 

10— @B 

22— @B 

* * 

i 

@C  = F3; 

1 

© 

n 

13— @C 

25— @C 

Two  DO  OCCURRENCE  statements  are  utilized  in  this  example  where  the 
inside  loop  goes  through  all  the  occurrences  of  repeating  group  RG2  for  each 
occurrence  of  repeating  group  RGl.  In  this  case,  three  passes  through  the 
assignment  statements  are  exercised. 


Example  4: 


DO  OCCURRENCE  RGl  END  (a) 


DO  OCCURRENCE  RG2  END  (p) 
DO  OCCURRENCE  RG3  END  (y  ) 


P-1 

P-2 

P-3 

P-4 

P-5 

@A  = 

FI: 

1— @A 

1 -@A 

1 — @A 

19— @A 

19-@A 

@B  = 

F2: 

4— @B 

10— @B 

10— @B 

22— @B 

22-@B 

@C  = 

F3: 

7— @C 

13-@C 

16-@C 

2 5-(3C 

28-@C 

1 I 


99 


w- 
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All  three  repeating  groups  are  controlled  by  DO  OCCURRENCE  loops  in  this 
example.  Note  now  that  five  passes  are  exercised  where  the  only  ambiguity 
remaining  with  value  selection  is  with  the  multivalued  fields  FI,  F2,  and  F3, 
In  all  cases,  the  "left-most-value"  is  selected  for  each  whole  occurrence  of 
the  field. 

Example  5: 

DO  OCCURRENCE  RGl  END  (a) 

DO  OCCURRENCE  Fl  END  ( p ) 

P-1  P-2  P-3  P-4  P-5  P-6 

A=F1:  1— @A  2-*@A  3— @A  19^@A  20— @A  21— @A 

B = F2:  4— @B  4— @B  4— @B  22— @B  22— @B  22— @B 

C = F3:  7— @C  7— <a?C  7— @C  25— @C  25— (SC  25— @C 

This  example  illustrates  the  use  of  a DO  OCCURRENCE  statement  control- 
ling the  value  occurrence  selection  of  multivalued  field  Fl.  Since  Fl  has 
three  value  occurrences  for  each  RGl  occurrence,  six  passes  are  exercised. 
In  this  example,  the  "left-most- value"  is  not  selected  each  time  for  Fl,  since 
the  DO  OCCURRENCE  statement  is  controlling  data  selection. 

Example  6; 

DO  OCCURRENCE  Fl  END  (a) 


P-1 

P-2 

P-3 

A = Fl: 

1— @A 

2— @A 

3— @A 

B = F2: 

4— @B 

4— @B 

4— @B 

C = F3: 

7— @C 

7— (SC 

7— (®C 

r 

j 


Report  76-C-0899-1 

This  last  example  illustrates  the  use  of  a DO  OCCURRENCE  statement  on  the 
field  of  FI  without  an  occurrence  control  on  repeating  group  RGl.  There- 
fore,. since  only  the  "left-most-occurrence"  of  RGl  is  considered,  the  sec- 
ond instance  of  FI  is  not  exercised, 

A.  3.  1.  3 Record.  Records  are  probably  UDL's  second  most  important  data 
structure  where  they  form  the  physical  unit  of  selectibility.  A record  can 
be  optionally  named,  where  if  it  is  named  the  name  refers  to  a type.  Indi- 
vidual records  are  not  named.  Records  are  defined  by  the  fields  and  aggre- 
gates defined  under  them.  All  records  of  a given  record-type  have  the  same 
logical  structure  where  the  same  fields  and  aggregates  are  present.  This 
does  not  necessarily  imply  that  all  records  of  a given  record-type  are  the 
same  size;  true  multioccurring  data  structures  such  as  multivalued  fields  or 
repeating  groups  can  have  an  arbitrary  number  of  occurrences  for  any 
record. 

A.  3.  1. 4 Files.  A file  is  a named  collection  of  records.  A file  may  con- 
tain more  than  one  record-type,  where  the  types  must  be  named  if  more  than 
one  is  present.  A file  is  the  largest  data  structure  which  an  interrogation  or 
update  statement  can  reference. 

A.  3.  1.  5 Data  Base.  A data  base  is  a collection  of  files,  where  it  can  be 
roughly  thought  of  as  synonymous  with  a given  target  system. 

A.  3.  2 Data  Types 

Data  types  designate  the  nature  of  the  data  that  a field  may  contain.  UDL 
data  types  can  be  of  three  basic  types:  character,  numeric,  and  geographic. 
Character  data  are  further  divided  into  three  groups:  variable-length-text, 
fixed-length-text,  and  alphanumeric.  The  further  classifications  of  charac- 
ter data  type  are  based  on  a usage  consideration  rather  than  one  of  differences 
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in  structure.  As  will  be  shown  in  figure  A-7,  the  CONTAINS  operator  is 
valid  only  for  those  fields  with  a character  data  type  of  variable  or  fixed- 
length-text.  For  fixed- length-text  fields,  the  EQ  operator  is  also  legal  (it  is 
not  for  variable-length-text).  If  a field  is  designated  with  a variable-length 
or  fixed-length-text  character  data  type,  the  unit  of  searchability  must  also 
be  specified.  This  unit  is  either  a single  character  or  a "word.  " This  unit 
determines  the  smallest  scan  unit  of  the  CONTAINS  operator.  A "word"  unit 
is  usually  applicable  for  files  set  up  for  special  document  retrieval  applica- 
tions. The  third  character  data  type,  alphanumeric,  is  valid  with  the  EQ  op- 
erator only.  Numeric  data  types  specify  that  a field  contains  data  of  a purely 
nximeric  nature.  Two  numeric  data  types  are  available  in  UDL:  fixed-point 
and  floating-point.  For  fields  designated  with  a numeric  data  type,  the  EQ 
operator  plus  all  the  standard  relational  operators  (i.  e.  , GT,  LT,  etc.  ) are 
valid.  The  special  geographic  data  type  is  for  fields  that  contain  geographic 
data.  Geographic  data  always  contain  the  positional  dyad  latitude /longitude. 
The  special  geographic  operators,  INSIDE,  OUTSIDE,  and  ALONG,  are 
used  exclusively  with  fields  designated  with  a geographic  data  type. 

All  UDL  fields  must  have  a designated  data  type.  All  constants  placed  into 
these  fields  must  conform  to  this  data  type.  Refer  to  paragraph  A.  2.  3 for 
definition  of  UDL  data  constants. 

A.  3.  3 Data  Attributes 

Data  attributes,  as  data  types,  are  associations  placed  on  fields.  Data  attri- 
butes affect  a field's  operability  with  the  UDL  statement  set.  Three  attribute 
classifications  must  be  designated  for  a UDL  field: 


a.  Interrogation. 

b.  Display. 

c.  Update. 
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The  interrogation  attribute  can  be  one  of  three  kinds:  keyed,  nonkeyed,  and 
dependent.  Fields  with  a data  attribute  of  "keyed"  can  be  referenced  in  any  FIND 
statement.  That  is,  there  are  no  restrictions  to  its  being  used  in  se- 
lection criteria.  A field  designated  as  dependent  can  also  be  utilized  in  a 
FIND  statement.  However,  this  must  be  a dependent  FIND  statement  where 
its  record  source  is  from  a previous  FIND  statement.  Therefore,  a field 
designated  as  dependent  cannot  be  referenced  in  an  initial  FIND  statement. 
Fields  designated  as  nonkeyed  cannot  be  referenced  in  a FIND  statement. 


The  display  attribute  can  be  one  of  two  kinds:  visible  or  invisible.  Fields 
designated  with  a data  attribute  of  visible  can  be  displayed  via  the  DISPLAY, 
HEADER,  and  TRAILER  statements.  Fields  designated  invisible  cannot  be 
displayed  at  all. 


The  update  attribute  determines  whether  a field  is  major  or  nonmajor. 
Major  fields  must  always  be  initialized  in  the  CREATE  statement  and  in  the 
ADD  statement  if  they  are  a major  field  in  a repeating  group  occurrence. 
Similarly,  major  fields  which  are  contained  in  a repeating  group  cannot  be 
entirely  deleted  by  the  DELETE  statement  (assuming  they  are  multivalued). 

There  are  no  update  restrictions  for  fields  designated  as  nonmajor. 

All  UDL  fields  must  be  assigned  a data  attribute  triad,  namely  one  desig- 
nating interrogation,  display,  and  update  attributes. 


A.  4 UDL  STATEMENTS 


A.  4.  1 Overview 


UDL  statements  are  grouped  into  four  categories: 


a.  Interrogation  statements. 

b.  Display/report  generation  statements. 


m 
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c.  Update  statements. 

d.  Data  manipulation  statements. 

There  is  only  one  interrogation  statement  in  UDL,  the  FIND  statement.  FIND 
selects  records  from  a target  system  file  based  on  specified  selection 
criteria. 

Report  generation  statements  allow  the  user  to  obtain  a simple  display  of 
what  he  has  selected  or,  at  the  other  extreme,  to  produce  a sophisticated 
report  based  on  a complex  display  list  and  format  statement.  The  DISPLAY 
statement  can  be  used  in  conjunction  with  ihe  FORMAT  statement  to  generate 
the  output.  Other  UDL  statements  associated  with  report  generation  are 
TABSET  (establishes  new  user  tab  settings),  ON  (activates  the  output  of 
header  and  trailer  lines),  OFF  (deactivates  the  output  of  header  and  trailer 
lines),  HEADER  (defines  the  format  of  a header  line),  and  TRAILER  (defines 
the  format  of  a trailer  line). 

Update  statements  allow  the  UDL  user  to  alter  a file  in  several  ways.  The 
REMOVE  statement  removes  entire  records  from  a target  system  file.  To 
add  entire  new  records  to  a target  system  file,  the  user  enters  the  CREATE 
statement  along  with  a list  of  field-name/value  pairs  which  describe  the  new 
record  to  be  added.  When  an  existing  record  is  to  be  changed,  the  CHANGE 
statement  will  accomplish  this.  The  parameters  specified  are  field  names  of 
the  fields  to  be  changed  and  the  new  values  for  these  fields.  Two  update  state- 
ments are  available  to  modify  records  in  which  there  are  occurrences  of 
multivalued  fields  and  repeating  groups.  The  ADD  statement  allows  the  user 
to  add  new  field  occurrences  (under  a repeating  group)  or  new  value  oc- 
currences (in  a multivalued  field).  The  DELETE  statement  does  the  reverse 
of  ADD;  it  is  used  to  delete  these  occurrences. 
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The  data  manipulation  capability  in  UDL  is  integral  to  the  entire  UDL  lan- 
guage and  allows  the  user  to  intersperse  other  UDL  statements  and  com- 
mands with  the  data  manipulation  statements.  There  are  four  general  kinds 
of  data  manipulation  statements: 

a.  Loop  control. 

b.  Execution  control. 

c.  Data  processing. 

d.  Declaration. 

Loop  control  statements  involve  the  setup  and  control  of  loops  based  on  either 
a specified  number,  the  number  of  records  on  a list,  the  number  of  occur- 
rences of  a specified  data  structure,  or  the  number  of  unique  values  occurring 
in  a specified  field.  Execution  control  statements  include  an  IF-THEN- 
ELSE  statement,  a GOTO  statement  (both  simple  and  computed),  and  a CALL 
statement  (to  transfer  control  to  a procedure).  There  are  several  data  proc- 
essing statements  available  for  list  control,  and  an  assignment  statement 
which  assigns  a value  to  a variable  based  on  the  evaluation  of  a numeric- 
expression.  Declaration  statements  allow  the  user  to  name  and  define  a 
variable,  and  to  name  and  define  a procedure. 

A.  4.  2 Interrogation  Statements 

Interrogation  statements  in  UDL  are  vised  to  isolate  records  from  a file  by 
specifying  a set  of  selection  criteria  against  that  file.  Interrogation  does  not 
display  a file  but  only  isolates  records  for  subsequent  display,  updating, 
and/or  mainipulation.  This  paragraph  describes  the  syntax  and  semantics  of 
UDL's  interrogation  facility,  the  FIND  statement. 
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A.  4,  2.  1 Syntax. 

<£ind-statement>  = FIND  <source-clause>  <selection-criteria> 

<source-clause>  = IN  <file-name>  | SOURCE  (<tag>) 

<selection-criteria>  = <seIection-clause>  OR  <seIection-criteria>  | 

<s  election -clause> 

<selection-clause>  = <selection-phrase>  AND  <selection-clause>  1 

<selection-phrase> 

<selection-phrase>  = <selection-factor>  <log-op>  <selection-phrase>  1 

<s  election -facto  r> 

<log-op>  = XOR  1 NOR 

<selection-factor>  = NOT  <selection-factor>  | <selection-primary> 

<selection-primary>  = <scope-q\iali£ier>  (<selection-criteria>)  j 

(<selection-criteria>)  ] <selection-term> 
<scope-quali£ier>  = <repeating-group-name> 

<selection-term>  = <rel-terml>  [ <rel-term2>  | <rel-term3> 

<rel-terml>  = <£ield-term>  <rel-opl>  <restricted-num-exp> 

<rel-opl>  = EQ  I GT  I LT  I GE  I LE  I CONTAINS 

<rel-term2>  = <£ield-term>  <rel-op2>  <restricted-num-exp>, 

<restricted-num-exp> 

<rel-op2>  = WRG  | ORG 

<rel-term3>  = <£ield-term>  <rel-op3>  <geo-exp> 

<rel-op3>  = INSIDE  1 OUTSIDE  | ALONG 

<geo-exp>  = <circle-exp>  | <poly-exp>  | <route-exp> 

<circle-exp>  = CIRCLE  (<radius -term>,  <lat-long-term>) 

<poly-exp>  = POLY  (<lat-long-list>) 

<route-exp>  = ROUTE  (<band-term>,  <lat-long -list>) 
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<lat-long-list>  = <lat-long-terTn>,  <lat-long-list>  | <lat-long-term> 

<lat-long-terin>  = <variable-term>  | <geographic-constant> 

<radius-teriTi>  = <restricted-num-exp> 

<band-terin>  = <restricted-num-exp> 

<source-arg>  = <tag> 

A.  4.  2.  2 Semantics.  The  optional  source  specification  must  be  a statement 
label  of  another  FIND  statement.  FIND  statements  with  a source  specifica- 
tion are  called  dependent  FIND  statements  where  they  isolate  records  from  a 
set  of  records  previously  isolated  by  one  or  more  other  FIND  statements. 

The  selection-criteria  is  a specialized  boolean- expression  used  exclusively 
for  record  selection.  Its  form  is  very  similar  in  some  respects  to  the 
boolean- expre s sions  defined  in  paragraph  A.  2.  4.  Legal  boolean  operators 
for  selection-criteria  are  OR,  AND,  XOR,  NOR,  and  NOT  where  they  have 
the  same  definition  and  operation  precedence  as  defined  for  boolean-expres- 
sions in  paragraph  A.  2.  4.  The  argument  of  a boolean  term  (called  a 
selection-primary)  can  be  either  a selection-term,  which  is  composed  of 
three  relational  term  types,  or  other  selection-criteria  enclosed  in  paren- 
theses with  an  optional  scope -qualifier.  For  any  given  set  of  selection- 
criteria,  the  maximum  scope  of  operation  is  over  a record.  This  is  called  a 
selection-criteria's  implicit  scope.  For  complex  hierarchical  structures 
within  a record,  it  is  also  desirable  to  be  able  to  limit  Scopes  of  operation  to 
various  subtrees  of  the  structure.  The  scope -qualifier  has  been  designed  to 
do  this. 

The  sc  ope -qualifier  must  be  the  name  of  a repeating  group.  Selection- 
criteria  qualified  by  a scope-qualifier  is  forced  to  satisfy  that  criteria  for 
the  same  occurrence  of  the  named  repeating  group.  This  also  implies  that 
the  field-terms  referenced  in  the  qualified  selection-criteria  must  be  defined 
directly  or  indirectly  for  the  named  repeating  group.  Indirectly  defined 
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means  a field  may  be  defined  for  another  repeating  group  which,  in  turn,  is 
defined  for  the  named  repeating  group.  The  scope-qualifier  will  affect  the 
selection  process  result  only  if  there  exist  two  or  more  selection-primaries 
as  arguments  of  the  scope -qualifier  such  that  one  or  more  of  the  logical 
connectors  is  an  AND  (after  the  selection-criteria  has  been  reduced  to 
di  s junctive  - no  rmal  - fo  rm) . 

Scope -qualifiers  can  also  be  nested  to  force  the  desired  lineage  path  during 
the  selection  process. 

Since  the  scope -qualifier  is  only  applicable  for  criteria  which  are  connected 

/ 

by  an  AND  operator,  complex  selection-criteria  can  be  difficult  to  analyze 
with  respect  to  its  scope -qualifier.  Complex  selection-criteria  under  the 


scope  of  a repeating  group  can  be  reduced  to  a more  understandable  form 


with  the  application  of  three  rules: 


a.  Reduce  the  selection-criteria  to  disjunctive-normal-form. 

b.  Distribute  the  scope -qualifier  through  the  various  disjuncts. 

c.  Drop  the  scope -qualifier  from  any  single-term  disjunct. 

The  result  is  a series  of  scope -qualified  terms  or  unqualified  single-terms, 
connected  by  OR-operators. 


Relational  terms  can  be  divided  into  four  basic  groups: 

a.  Standard  relational  terms. 

b.  Textsc.in  relational  terms. 

c.  Range  relational  terms. 

d.  Geographic  relational  terms. 


j 

j 
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See  figure  A-7  for  the  valid  combinations  of  relational  operators  and  data 
types. 

A.  4.  2.  2.  1 Standard  Relational  Terms.  Standard  relational  terms  contain 
the  operators  EQ,  LT,  GT,  LE,  and  GE.  These  operators  follow  the  same 
definition  as  provided  in  paragraph  A.  2.  4.  2.  1. 

A.  4.  2.  2.  2 Textscan  Relational  Terms.  Textscaji  relational  terms  contain 
the  single  operator  CONTAINS.  The  CONTAINS  operator  performs  a unit- 
by-unit  scan  of  the  specified  field-term  for  the  value  depicted  by  the  expres- 
sion. A field-term  must  have  a data-type  of  either  variable -length-text  or 
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Figure  A-7.  Legal  Combinations  of  Data  Types  and  Selection-Criteria 
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fixed-length-text  if  it  is  to  be  referenced  by  the  CONTAINS  operator.  Simi-  ; 

larly,  the  calculated  value  of  the  expression  must  be  a character  type.  The 
unit  of  the  CONTAINS  operation  is  specified  in  the  data  type.  Either  a 
character-by-character  search  or  a data  word-by-data  word  search  is  per- 
formed on  the  field-term.  The  "mask"  character  (?)  described  in  paragraph 
A.  2.  1 can  be  utilized  in  masking  out  characters  in  the  value  represented  by 
the  expression  (e.  g.  , NAME  CONTAINS  SCHMI?  ). 


A.  4.  2.  2.  3 Range  Relational  Terms.  Two  operators  are  provided  for  range 
operations:  WRG  and  ORG.  The  WRG  operator  requires  that  the  field-term 
be  within  or  equal  to  the  limits  established  by  the  two  specified  expressions. 
The  first  expression  specifies  the  lower  range  limit,  and  the  second  expres- 
sion specifies  the  upper  range  limit.  The  ORG  range  requires  that  the  field- 
term  be  outside  the  range  established  by  the  two  expressions. 

A.  4.  2.  2.  4 Geographic  Relational  Terms.  Geographic  relational  terms 
apply  to  field-terms  (with  a geographic  data  type)  and  their  relationship  to  a 
specified  set  of  circles,  routes,  or  n- sided  polygons  on  the  surface  of  the 

earth.  Three  geographic  operators  and  three  specialized  geographic-expres- 

i 

1 sions  are  recognized  in  UDL. 

The  INSIDE  operator  requires  that  a field-term's  geographic  value  (latitude/ 
longitude  constant)  be  inside  the  area  specified  by  the  geographic-expression. 
Similarly,  the  OUTSIDE  operator  requires  that  a field-term's  value  be  out- 
side the  area  specified,  and  the  ALONG  operator  requires  that  the  value 
specified  in  the  field-term  be  on  the  perimeter  of  the  specified  area.  The 
specialized  geographic-expression  can  specify  either  a circle,  an  n-sided 
I polygon,  or  a multiple  directioned  route.  For  a route,  the  OUTSIDE  and 

I- 

INSIDE  operators  are  equivalent  where  they  both  mean  "off  the  route.  " For 
a circle,  both  the  center  and  radius  must  be  established.  A route  is 
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established  by  specifying  the  points  it  lies  on  and  the  width  of  the  route. 
Polygons  are  determined  by  a list  of  latitude /longitude  specifications.  Refer 
to  paragraph  A.  2.  3 for  the  synteix  and  semantics  of  geographic-constants. 

Upon  completion  of  the  FIND  statement,  the  nximber  of  records  satisfying 
the  selection-criteria  is  displayed  to  the  user  as  follows: 

NUMBER  OF  RECORDS  FOUND  = number 

All  FIND  statements,  dependent  or  otherwise,  display  this  record  count  upon 
their  completion. 

A.  4.  3 Display/Report  Generation  Statements 

UDL  display  statements  provide  the  user  with  a facility  for  outputting  data 
extracted  from  files  in  a user-oriented  format.  Data  formatting  and  print 
control  operations  can  be  controlled  by  the  user  for  the  generation  of  sophis- 
ticated reports.  UDL.  recognizes  seven  display / report  generation  statements: 

a.  DISPLAY. 

b.  FORMAT. 

c.  HEADER. 

d.  TRAILER. 

e.  ON. 

.f.  OFF. 

g.  TABSET 

Following  are  the  syntax  and  semantics  for  these  seven  commands. 

A.  4.  3.  1 Syntax. 

<display- statement>  = DISPLAY  <display-clause>  | DISPLAY 

<display-clause>  = <source-spec>  <display-phrasel>  1 <source- 


spec>  1 <display-phrase  1 > 
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<display-phrasel> 


<display-list> 


<display-element> 


<di  s pi  ay  - ite  m> 

<occur  rence-qualifie  r> 

<display-qualifier> 

<do-group> 

<do-spec> 

<do  - range  -list> 
<do-element> 


<max-  speci£ication> 
<rgn-list> 


<di  splay -phrase2> 


f 

I 

I <£ormat-spec> 

I <dest-spec> 

r 

[ <source-spec> 

I 

I <source-arg> 

<£ormat-declaration> 


I 

I 

I 


= <display-list>  <display-phrase2>  | <display- 
list>  I <display-phrase2> 

= <display-element>,  <display-list>  | <display- 
element> 

= <occurrence-quali£ier>  (<display-list>)  | <do- 
group>  I <display-quali£ier>  < display-item>  | 
<display-item> 

= TREE  (<repeating-group-name>)  | <numeric- 
expression>  | <array-term>  | <repeating-group- 
term> 

= <repeating-group-term> 

= LOCSC  (<selection-criteria>) 

= {<display-list>  DO  <do-spec>) 

= <variable-term>  = <do-range -list> 

= <do-element>,  <do-range-list>  1 <do-element> 

= <numeric-expression>  TO  <^ax-speci£ication>  1 
<numeric-expres sion>  TO  <m£ix-speci£ication> 

BY  <numeric-expression>  1 <numeric- 
expression> 

= <numeric-expression>  | MAX  (<rgn-list>) 

= <repeating-group-name>,  <rgn-list>  | <repeating- 
group-name> 

= <£ormat-spec>  <dest-spec>  | <£ormat-spec>  | 
<dest- spec> 

= USE  (<tag>)  I <£o rmat-declaration> 

= REMOTE  (<remote-arg>) 

= SOURCE  (<source-arg>) 

= <tag>  1 <list-name> 

= FORMAT  (<£ormat-list>) 


.4 
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I 

f 

I 


<format-list> 


<f  o r ma  t - e le  ment> 


<line-arg>  = 

<display-activate>  = 

<display-term>  = 

<ite  ration- speO  = 

<header-statement>  = 

<header-trailer-number>  = 
<header-trailer-clause>  = 
<trailer-statement>  = 

<on-statement>  = 

<header-trailer-qualifier>  = 
<off-statement>  = 

<tabset-statement>  = 

<tab-list>  = 


<format-element>,  <£ormat-list>  | Cformat- 
elenrient> 

PAGE  I LINE  (<line-arg>)  | SKIP  (<numeric- 
expression>)  1 TAB  | TRESET  | SPACE 
{<numeric-expression>)  | RETURN  | <display- 
activate>  | <iteration-spec>  1 USE  {<tag>) 
<numeiic-expre  ssion>,  <numeric-expression> 
<numeric-expre  ssion> 

VERT  (<display-terni>)  | <display-terni> 
CURRENT  1 AT  (<numeric-expression>)  1 TO 
(<nuineric-expression>) 

<max  - spe  c if ic  ation>  ( <f o rmat  -li  st>) 

HEADER  <header-trailer-number>  <header- 
trailer-clause> 

<digit>  <digit>  <digit>  | <digit>  <digit>  1 <digit> 
<display-list>  <fo rmat- spe c>  | <di splay -list> 
TRAILER  <header-trailer-number>  <header- 
trailer-clause> 

ON  <header-trailer-qualifier>  <numeric- 
expression> 

HEADER  I TRAILER 

OFF  <header-trailer-qualifier>  <numeric- 
expre  ssion> 

TABSET  <tab-list> 

<numeric-expression>,  <tab-list>  | <numeric- 
expression> 
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A.  4 . 3 . 2 Semantics. 

A.  4.  3.  2.  1 DISPLAY  Statement.  The  DISPLAY  statement  operates  on  a list 
of  records.  These  records  may  be  on  a user- specified  list  or  they  may  be 
on  an  implicit  list  generated  by  the  FIND  statement.  DISPLAY  statements 
may  operate  independently  where  they  specify  the  record  source  via  the  op- 
tional parameter,  SOURCE,  or  they  may  be  embedded  in  a DO  RECORD  or 
DO  VALUE  loop  where  the  record  source  is  specified  by  these  statements. 

If  a DISPLAY  statement  specifies  a record  source  and  is  embedded  in  a DO 
RECORD  or  DO  VALUE  loop,  the  explicit  source  specification  has 
precedence. 

If  a display-list  is  not  specified,  the  entire  record(s)  is  displayed.  If  the 
DISPLAY  statement  is  embedded  in  a DO  RECORD  or  DO  VALUE  loop,  the 
entire  record  that  is  current  in  the  loop  is  displayed.  If  the  record  source 
is  specified  in  the  DISPLAY  statement,  all  records  are  displayed  in  their 
entirety. 

The  display-list  is  a list  of  data  structures  below  the  record  level  which 
provide  the  user  with  a selective  and  ordered  mechanism  for  displaying  por- 
tions of  a record.  The  fundamental  element  of  a display  list  is  the  display- 
item.  Display-items  can  be  one  of  three  basic  kinds:  a numeric -express ion, 
an  array-term,  or  a repeating-group-term.  In  addition,  an  entire  repeating 
group  may  be  displayed  by  using  the  TREE  qualifier.  The  display  of  field- 
terms  and  variable -terms  is  allowed  through  the  display  of  numeric- 
expressions  where  a single  field-term  or  variable -term  are  valid  forms. 

Other  more  sophisticated  constructs  are  allowed  in  a display  list.  These 
are:  a display-qualifier,  DO-loop  facility,  and  an  occurrence-qualifier. 

The  display -qualifier,  denoted  by  LOCSC,  allows  the  user  to  further  qualify 
the  selected  records  with  respect  to  a single  display-item.  That  is,  before  a 
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specified  display-item  is  output  for  a given  record,  the  selection-criteria 
denoted  as  the  display-qualifier  must  be  satisfied  by  that  record.  If  a 
display -qualifier  is  not  specified  for  a given  display-item,  that  display-item 
will  be  displayed  for  each  record.  The  DO-loop  facility  allows  a user  to 
embed  a DO-loop  inside  a DISPLAY  statement.  The  scope  of  the  DO-loop 
may  be  a difeplay-list  which  is  specified  prior  to  the  DO-loop  specification 
inside  the  '*do-group"  parentheses  (see  syntax).  The  DO-loop  specification 
follows  essentially  the  same  form  as  the  DO  statement  described  in  para- 
graph A.  4.  5.  A user  may  specify  a list  of  do-elements  where  each  do- 
element  is  satisfied  left -to- right.  A do-element  may  consist  only  of  a single 
component  hence  causing  the  loop  to  occur  only  once,  or  a range  may  be 
specified  where  the  variable-term  specified  is  indexed  by  one  starting  from 
the  initial  value  up  to  and  including  the  final  value.  If  the  BY  option  is 
utilized,  the  variable-term  is  indexed  by  the  value  specified  in  its  argument. 

The  max- specification  can  either  be  a numeric-expression  or  a repeating- 
group-name  list.  The  repeating -group-name  list  is  used  when  a DO-loop 

encompasses  all  occurrences  currently  present  in  a set  of  repeating  groups.  ^ 

\ 

If  more  than  one  repeating -group-name  is  specified,  they  must  be  defined  at  j 

the  same  level;  i.  e.  , have  the  same  parent  repeating  group.  The  max-speci-  j 

fication  is  evaluated  dynamically  where  it  takes  on  the  value  equal  to  the  i 

number  of  occurrences  of  the  repeating  group  with  the  most  occurrences  for 
a given  instance  (a  repeating  group  may  have  many  instances  if  it  is  sub- 
ordinate to  another  repeating  group).  As  the  instances  are  transgressed, 
the  maix- specification  is  altered  accordingly. 

The  occurrence-qualifier  provides  the  user  with  the  facility  to  control  the 
display  of  repeating  group  occurrences.  Its  operation  is  analogous  to  the 
DO  OCCURRENCE  statement  defined  in  paragraph  A.  4.  5.  The  argument  of 
an  occurrence-qualifier  is  a display-list. 
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Since  the  argument  scope  for  both  a DO-block  and  occurrence-qualifier  can 
be  a display-list,  all  display  items  types  are  legal  (including  other  DO-blocks 
and/or  occurrence-qualifiers).  In  order  to  specify  the  precise  operation  of 
the  occurrence-qualifier  and  how  it  interacts  with  the  DO-loop  facility,  four 
basic  cases  are  described: 

a.  Occurrence-qualifier  (unsubscripted). 

b.  Occurrence-qualifier  (subscripted). 

c.  Occurrence -qualifier  inside  a DO-loop. 

d.  DO-loop  inside  an  occurrence-qualifier. 

The  occurrence-qualifier  (unsubscripted)  takes  the  format: 

rgn  (X  . ....  X ) 

I n 

In  this  case,  the  repeating -group-name  (rgn)  is  an  occurrence-qualifier 
which,  for  a given  set  of  display -items,  Xi  — Xni  forces  value  selection  to 
be  performed  in  a group  corresponding  to  the  occurrences  of  the  specified 
repeating  group.  That  is,  value  selection  is  performed  for  Xj  through  X^ 
for  the  first  occurrence  of  rgn,  then  value  selection  is  again  performed  for 
all  Xi  for  the  second  occurrence  of  rgn,  and  so  on.  If  the  value  selection 
were  not  qualified  by  rgn,  the  value  selection  would  be  performed  on  Xj^  for 
all  occurrences  of  rgn,  then  all  occurrences  of  X2,  etc. 

The  occurrence-qualifier  (subscripted)  takes  the  format: 

rgn  (subscript)(Xj,  . . . , X^) 

This  case  behaves  as  the  previous  case  except  value  selection  for  X^  — X^ 
is  performed  for  only  one  occurrence  of  rgn,  namely  the  occurrence  pointed 
to  by  "subscript.  " 
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The  occurrence-qualifier  inside  a DO-loop  takes  the  format; 

(rgn  (X,.  ....  X ) DO  ...) 

This  case  illustrates  a nested  loop  condition  where  the  DO-loop  is  the  "out- 
side loop.  " For  each  index  value  taken  on  by  the  DO-loop,  value  selection  is 
performed  on  Xj  — X^  for  all  occurrences  of  rgn  as  described  in  the  first 
case. 

The  DO-loop  inside  an  occurrence-qualifier  takes  the  format: 

rgn  ((X,,  ....  X DO  . ..)) 

1 n 

This  case,  as  in  the  previous  case,  is  a nested  loop  condition.  However,  in 
this  situation,  the  repeating  group  qualifier  forms  the  "outside  loop.  " Hence, 
for  each  occurrence  of  rgn,  the  DO-loop  is  completely  transgressed. 

A.  4.  3.  2.  1.  1 General  Comments  on  tlie  UDL  Default  Display  Format.  If  a 
format-specification  is  not  specified  in  a DISPLAY  statement,  the  UDL  de- 
fault format  will  be  used.  This  format  provides  a simple  means  for  a user 
to  display  fields  and  aggregates  of  records  without  undo  concern  about  data 
formatting  and  general  print  control  procedures. 

Figure  A-8  illustrates  the  actual  UDL  default  format  as  it  applies  to  the 
various  kinds  of  fields  and  aggregates.  Due  to  the  inherent  nature  of  hier- 
archical structures,  records  which  contain  levels  of  repeating  groups  will  be 
displayed  with  the  tree  structure  intact,  regardless  of  the  order  of  the  speci- 
fied display-items.  Data  structures  defined  for  the  same  repeating  group, 
however,  will  be  displayed  in  the  order  they  are  specified  in  the  display- 
list.  A repeating  group  display-item  will  cause  the  display  of  all  occur- 
rences (assuming  local  selection  criteria  are  not  specified  on  this  display- 
item)  of  the  specified  repeating  group  at  its  data  set  level  only;  that  is. 
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Single -Valued  Field/Concatenated  Field 
field-name  = value 

Multivalued  Field/Concatenated  Field 
field-name  = value 

= value  2 

= vaiucj^ 

Array 

array-namel  (1) 

fie  Id -name  = value 
array-nameZ  (1,1) 

field- name  = value 
field-name  = value 
array-nameZ  (1,  Z) 

field-name  = value 
field-name  = value 
array-namel  (Z) 

field-name  = value 
array-nameZ  (Z,  1) 

field-name  = value 
field-name  = value 
array-nameZ  (Z,  Z) 

field-name  = value 
field-name  = value 

Repeating  Group 

Repeating  group-namel 
field -name  = value 
field-name  = value 

Figure  A-8,  UDL  Default  Display  Format  (Sheet  1 of  Z). 
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Repeating  group-nameZ 
field- name  = value 
repeating  group-name3 
field-name  = value 
repeating  group-name 3 
field -name  = value 
Repeating  group-name  1 
fie  Id -name  = value 
fie  Id -name  = value 
repeating  group-nameZ 
field-name  = value 


Figure  A-8.  UDL  Default  Display  Format  (Sheet  Z of  Z). 

subordinate  repeating  groups  will  not  be  displayed.  A repeating  group  dis- 
play-item qualified  by  TREE  behaves  as  the  situation  just  described  except 
all  subordinate  repeating  groups  are  also  displayed  (as  shown  in  figure  A-8). 

If  a list  of  field-terms  is  specified  as  a set  of  display-items  where  they  are 
embedded  in  a hierarchical  structure  of  repeating  groups,  the  minimum  tree 
structure  which  encompasses  all  the  specified  field-terms  will  be  dis- 
played. Repeating  group  names  will  also  be  displayed  as  node  markers, 
where  they  will  be  inserted  into  the  proper  places  of  the  tree.  Combinations 
of  field-terms,  repeating-group-terms,  and  array-terms  may  be  specified  in 
the  same  display-list.  The  display  for  each  display -item  behaves  as  shown 
in  figure  A-8.  Each  record  displayed  will  contain  the  minimum  tree 
structure  which  encompasses  the  displayed-items.  As  brought  out  earlier 
in  this  section,  if  a display-rlist  is  not  specified,  tlie  entire  record  is  dis- 
played. Thus  if  repeating  groups  arc  present  in  the  record  definition,  the 
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A record  header  will  be  displayed  at  the  top  of  each  print  page.  This  record 
header  will  contain  the  following  information: 

(file -name)  RECORD  NUMBER  IS  number 

A.  4.  3.  2.  1.  2 User-Directed  Display  Format.  If  the  user  desires  a more 
sophisticated  display  output,  he  may  circumvent  the  UDL  default  display  for- 
mat by  specifying  a format -specification.  Format- specifications  can  be 
made  either  in  the  DISPLAY  statement  itself  or  tlie  format-specification  can 
be  remotely  specified  by  pointing  to  a FORMAT  statement  via  its  statement 
label.  Format-specifications  can  be  used  in  conjunction  with  a display-list, 
or  they  can  be  used  with  the  entire  record  if  a display-list  is  not  specified, 
paragraph  A.  4.  3.  2.  2 elaborates  on  display-list/format-list  interaction. 

A.  4.  3.  2.  1.  3 Display  Destination.  The  user  may  specify  where  the  output 
is  to  be  displayed  by  utilizing  the  optional  dest-  specification.  If  REMOTE 
is  specified,  the  output  will  go  to  one  of  the  system's  high-speed  line  print- 
ers. The  default  case  is  the  requesting  input/output  console. 

A.  4.  3.  2.  2 FORMAT  Statement.  The  UDL  FORMAT  statement  used  in  con- 
junction with  the  DISPLAY  statement  provides  the  user  with  a very  sophis- 
ticated report  generation  capability.  A FORMAT  statement  is  composed  of 
a of  format-elements.  Format-elements  can  be  divided  into  three  basic 
types:  those  which  control  printlines,  spacing,  and  general  tabulation;  those 
which  cause  the  actual  display  of  data;  and  those  which  control  the  format- 
list.  Of  the  first  type,  PAGE,  LINE,  SWP,  TAB,  TRESET,  SPACE,  and 
RETURN  are  present.  CURRENT,  AT,  and  TO  (with  or  without  a VERT 
qualifier)  are  of  the  second  type,  and  iteration- specification  and  USE  are  the 
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third  type  of  format-elements.  Following  is  a description  of  those  format- 
elements. 

a.  PAGE  — causes  a top-of-form.  All  line/character  position  pointers 
are  reset. 

b.  LINE  (X,  Y)—  causes  the  line  position  pointer  to  be  set  to  line  X and 
character  position  pointer  to  Y.  If  Y is  not  specified,  the  character 
position  pointer  is  unaltered.  For  the  condition  where  X is  less  than 
the  current  line  position,  a top-of-form  is  performed  and  the  line 
position  pointer  is  set  to  X.  If  Y is  less  than  the  current  character 
position,  the  line  position  pointer  is  incremented  and  the  character 
position  pointer  is  set  to  Y.  As  is  implied  by  the  foregoing  condi- 
tions, UDL  does  not  allow  the  user  to  "backup"  a line  or  print  page. 

c.  SKIP  (X)  — causes  the  line  position  pointer  to  be  incremented  by  X. 
The  character  position  pointer  is  not  altered.  If  the  current  line 
position  plus  X exceeds  the  maximum  line  pointer  allowed  for  a 
print  page,  a top-of-form  is  performed  and  the  line  position  pointer 
is  set  to  (current-line  position  pointer)  +X-  ( maximum- line - 
position). 


d.  TAB  — causes  the  character  position  pointer  to  be  set  to  the  next  tab 
position.  If  the  tab  pointer  is  pointing  to  the  last  tab  position,  it  is 
then  set  to  the  first  tab  position  (cyclic)  and  the  line  position  pointer 
is  incremented. 

e.  TRESET  — causes  the  character  position  pointer  and  the  tab  pointer 
to  be  set  to  the  first  tab  position. 

f.  SPACE  (X)  — causes  the  character  positionpointer  to  be  incremented 
by  X.  If  the  value  exceeds  the  maximum  character  position,  the  line 
position  pointer  is  incremented  by  one  and  the  character  position 
pointer  is  set  to  (current-character  position  pointer)  +X-  (maximum- 
cha  racter -position). 

g.  RETURN  — causes  tlie  character  position  pointer  to  be  set  to  1 and 
the  line  position  pointer  to  be  incremented  by  one.  If  the  line  posi- 
tion pointer  exceeds  the  maximvim,  a top-of-form  is  performed  and 
the  line  position  pointer  is  set  to  1. 

h.  CURRENT  — causes  display  of  tlic  current  display-item,  left- 
justified  at  the  current  character  position.  If  in  the  course  of  dis- 
playing the  specified  display-item  the  character  position  pointer 
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equals  the  maximum  position,  the  line  position  pointer  is  incre- 
mented and  the  character-position  pointer  is  set  to  1 where  the 
display  is  then  continued. 

i.  AT(X)  — causes  display  of  the  current  display-item  left-justified  at 
character  position  X.  If  X is  less  than  the  current  character  posi- 
tion pointer,  the  line  position  pointer  is  incremented  by  one  and  the 
character  position  pointer  is  set  to  X,  If  X is  greater  than  the 
maximum  character  position,  the  line  position  pointer  is  incre- 
mented by  one  and  the  character  position  pointer  is  set  to  X - 
(maximum  character  position).  If  in  the  course  of  displaying  the 
specified  display-item  the  character  position  pointer  equals  the 
maximum  position,  the  line  position  pointer  is  incremented  and  the 
character  position  pointer  is  set  to  1 where  the  display  is  then 
continued. 

j.  TO(X)  — causes  display  of  the  current  display-item,  right-justified 
to  the  current  character  position  X.  If  X is  less  than  the  current 
character  position  pointer,  the  line  position  pointer  is  incremented 
by  one  and  the  character  position  pointer  is  set  to  X.  If  X is  greater 
than  the  maLximum  character  position,  the  line  position  pointer  is 
incremented  by  one  and  the  character  position  pointer  is  set  to  X - 

( maximum-  cha  r acte  r - po  sition) . 

k.  USE  (tag)  — causes  the  FORMAT  statement  pointed  to  by  tag  to  be 
utilized  at  this  point  in  the  current  FORMAT  statement. 

l.  X (...)  — causes  repeated  usage  of  the  format-elements  contained 
within  the  parentheses.  The  format-list  will  be  repeated  X-times. 

X may  be  either  a numeric-expression  or  a max- specification. 

Refer  to  discussion  of  max- specification  in  DISPLAY  statement. 

Display-terms  may  be  optionally  qualified  with  the  VERT  qualifier.  The 
VERT  qualifier  is  applicable  with  multivalued  fields  or  named  multivalued 
fields  only.  Normally,  multivalued  fields  and  named  multivalued  fields  are 
displayed  in  a horizontal  list  (see  figure  A-9).  When  the  VERT  qualifier  is 
specified,  the  values  of  the  field  are  displayed  in  a column.  Each  value  is 
left -justified  to  the  same  character  position  if  AT  or  CURRENT  is  specified, 
or  right-justified  if  TO  is  specified.  If  AT  or  CURRENT  is  specified,  the 
final  character  position  is  that  position  following  the  value  with  the  most  char- 
acters in  it.  If  TO  (X)  is  specified,  the  final  character  position  is  the  posi- 
tion following  X. 
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Figure  A-9.  Horizontal  and  Vertical  Display  of  Multivalued  Fields. 


For  DISPLAY  statements  which  specify  a record  source,  the  display-list  is 
processed  completely  for  each  record.  The  accompanying  format-list  is 
processed  cyclically  for  all  records.  Tliat  is,  tlie  format-list  pointer  is  not 
reset  to  the  first  format -element  for  each  record  (unless,  of  course,  the  list 
happens  to  terminate  at  this  point).  When  a DISPLAY  statement  is  entered, 
its  display-list  pointer  and  the  associated  format-list  pointer  are  set  to  the 
beginning  of  their  respective  lists.  Therefore,  if  a DISPLAY /FORM AT 
statement  pair  is  under  the  control  of  a DO  RECORD  or  DO  VALUE  loop, 
both  list  pointers  are  reset  for  each  record  displayed.  The  flow  charts 
shown  in  figures  A- 10  and  A- 11  illustrate  tliis  display-list/format-list  inter- 
action. If  a record  source  is  specified  in  tlie  DISPLAY  statement,  the  proc- 
ess shown  in  figure  A-10  is  entered  once  and  terminates  when  all  records  are 
processed.  If  the  record  source  is  controlled  by  a DO  RECORD  or  DO  VALUE 
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loop,  the  process  terminates  after  one  iteration  through  the  display-list  and 
is  then  re-entered  again  for  each  record  (figure  A-11). 

A.  4.  3.2.3  HEADER  Statement.  The  HEADER  statement  establishes  a 
single  line  of  text  that  is  automatically  printed  at  the  top  of  every  print  page. 
This  statement  has  three  components:  a header-number,  a display-list,  and 
an  optional  format- specification.  The  header -number  is  an  integer  which 
represents  a logical  print  line  relative  to  the  top  of  the  print  page.  More 
than  one  header  may  be  established  at  any  one  time.  The  HEADER  state- 
ment is  a declarative  statement  and,  therefore,  does  not  cause  the  actual 
display  of  data.  The  header  must  be  "turned-on"  by  an  ON  statement  before 
it  becomes  active.  The  header  number  does  not  imply  a physical  line  posi- 
tion but  does  denote  a relative  ordering  with  respect  to  other  headers.  The 
header  with  the  smallest  header  number  is  printed  first. 

The  mandatory  display-list  is  identical  to  that  described  for  the  DISPLAY 
statement.  Similarly,  the  optional  format- specification  behaves  as  the 
FORMAT  statement. 

A.  4.  3.  2.  4 TRAILER  Statement.  The  TRAILER  statement  establishes  a 
single  line  of  text  that  is  automatically  printed  at  the  bottom  of  every  print 
page.  This  statement  has  the  same  components  as  the  HEADER  statement. 
The  trailer  number  is  relative  to  the  bottom  of  the  page.  Trailers  can  be 
activated  and  deactivated  by  the  ON  and  OFF  statements,  respectively. 

A.  4.  3.  2.  5 ON  Statement.  The  ON  statement  is  used  to  activate  both 
headers  and  trailers.  The  qualifiers  HEADER  and  TRAILER  determine 
which  type  is  to  be  activated,  and  an  integer  is  specified  to  denote  the  parti- 
cular header  or  trailer.  Since  the  integer  may  be  specified  as  a numeric - 
expression,  it  will  be  truncated  to  an  integer  if  a fractional  part  is  present. 
If  the  resulting  integer  is  not  a valid  header /trailer  number,  an  error 
diagnostic  will  be  output. 
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A.  4.  3.  2.  6 OFF  Statement.  The  OFF  statement  is  used  to  deactivate  both 
headers  and  trailers.  The  qualifiers  HEADER  and  TRAILER  determine  which 
type  is  to  be  deactivated,  and  an  integer  is  specified  to  denote  the  particular 
header  or  trailer. 

A.  4.  3.  2.  7 TABSET  Statement.  The  TABSET  statement  is  used  to  establish 
a set  of  column  tab  settings  to  be  used  in  conjunction  with  the  TAB  and 
TRESET  format  elements.  Tab  settings  must  be  integers  and,  therefore,  the 
evaluated  number -expression  will  be  truncated  to  an  integer  if  a fractional 
part  is  present.  Any  number  of  tab  settings  may  be  set,  where  they  must  be 
in  the  range  from  1 to  the  maximum  character  position. 

A.  4.  4 U pdate  Statements 

UDL  update  statements  provide  the  user  with  an  interactive  data  base  mainte- 
nance facility.  With  UDL  update  statements,  a user  may  add  or  delete 
records  from  a file,  alter  existing  field  values,  add  new  value  occurrences 
to  multioccur ring  fields,  or  delete  existing  value  occurrences.  Five  update 
statements  are  provided  in  UDL: 


a. 

REMOVE. 

b. 

CREATE. 

c. 

CHANGE. 

d. 

ADD. 

e. 

DELETE. 

Following  are  the  syntax  and  semantics  for  these  statements. 
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i 


A.  4.  4.  1 Syntax. 


<remove-statement> 
<create-  statement> 
<create-clause> 

<field- value -list> 

<field- value- element> 

<record-type-nanne> 
<change-  statement> 
<change-list> 

<change  - element> 

<change-part> 

<field-  speO 

<add-  statement> 

<add-list> 

<add-element> 

<add-item> 

<re3tricted-add-list> 
<delete  - 3tatem.ent> 
<delete-li3t> 


= REMOVE  SOURCE  (<tag>) 

= CREATE  IN  <file-name>  <c reate -clau3e> 

= RTYPE  (<record-type-name>)  <field- value-list>  | 
<field-value-list> 

= <field- value- element>  , <field- value-list>  | 
cfield- value-  element> 

= <repeating-group-name>  (<field- value-list>)  | 
<field-term>  EQ  <restricted-num- exp> 

= <name> 

= CHANGE  SOURCE  (<tag>)  <change-list> 

= <change- element>  , <change-list>  | 
<change-element> 

= OCC  (<selection-criteria>)  <change-part>  | 
<change-part> 

= <field-spec>  TO  <restricted-num-exp> 

= <field-name>  EQ  <restricted-num-exp>  | 
<field-term> 

= ADD  SOURCE  (<tag>)  <add-list> 

= <add-element>  , <add-list>  | <add- element> 

= OCC  (<selection-criteria>)  <add-item>  | 
<add-item> 

= <repeating- group-name>  (<restricted-add-list>)  ( 
<field-term>  EQ  <restricted-num-exp> 

= <add-itein>,  <restricted-add-list>  | <add-item> 

= DELETE  SOURCE  (<tag>)  <delete-list> 

= <delete-element>  , <delete-list>  | 

<delete-element> 


n 
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= OCC  (<selection-criteria>)  <delete-part>  | 
<delete-part> 

= <field-name>  EQ  <restricted-num-exp>  | 
<field-term>  | <repeating-group-name> 


A 4.  4.  2 Semantics. 

A 4.  4.  2.  1 REMOVE  Statement.  The  REMOVE  statement  deletes  records 
from  a file.  The  records  must  be  isolated  by  a previous  FIND  statement 
whose  statement  label  is  referenced  by  the  REMOVE  statement.  This  source 
specification  is  mandatory  for  the  REMOVE  statement.  All  records  isolated 
by  the  referenced  FIND  statement  are  deleted  from  the  file. 

A 4.  4.  2.  2 CREATE  Statement.  The  CREATE  statement  adds  a new 
record  to  a file.  If  the  file  contains  multiple  record  types,  the  record-type 
must  be  specified  via  the  RTYPE  qualifier. 

The  primary  component  of  the  CREATE  statement  is  a field-value-list  which 
is  used  to  assign  initial  values  to  the  fields  defined  for  that  record.  In  most 
situations,  it  is  not  necessary  to  assign  values  to  all  fields  in  order  to  create 
a new  record.  There  are  two  exceptions  to  this: 

a.  The  field  is  designated  as  a major  field. 

b.  The  fields  contained  in  a parent  repeating  group  must  be  assigned 

a value(s)  in  order  for  fields  in  a subordinate  repeating  group  to  be 
assigned  values;  that  is,  a repeating  group  occurrence  cannot  exist 
disjoint  from  the  record. 

A field-value-list  has  two  types  of  elements:  those  which  establish  value 
occurrences  for  a hierarchical  structure  (a  tree  of  repeating  groups)  and 
those  which  establish  a value  occurrence  for  a field.  A repeating  group 
occurrence  is  established  by  stating  its  name  and  then  specifying  the 
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appropriate  field  value  occurrences  defined  for  that  repeating  group.  This 
process,  of  course,  can  be  nested  if  subordinate  repeating  groups  are  to  be 
initialized  with  value  occurrences.  Fields  must  be  initialized  with  data  that 
are  compatible  with  the  data  type  defined  for  those  fields.  Field  values  may  be 
expressed  as  restricted-numeric-expressions,  hence  great  flexibility  is 
afforded  the  user  in  record  creation. 

A.  4.  4.  2.  3 CHANGE  Statement.  The  CHANGE  statement  allows  a user  to 
change  existing  value  occurrences  in  fields  for  a set  of  records.  The 
records  must  have  been  previously  isolated  by  a FIND  statement  whose 
statement  label  is  referenced  by  the  CHANGE  statement.  The  record 
source  specification  is  mandatory  for  the  CHANGE  statement.  All  records 
have  the  specified  changes  made  to  them. 

The  primary  component  of  the  CHANGE  statement  is  the  change-list.  The 
change-list  is  composed  of  change-parts,  qualified  or  unqualified.  Qualified 
change-parts  are  valid  for  repeating  groups  only,  where  the  selection- 
criteria  inside  the  OCC  parameter  isolates  the  repeating  group  occurrences 
the  change  is  applicable  for.  Depending  on  the  selectivity  of  the  criteria, 
one  or  many  repeating  group  occurrences  may  be  affected  by  the  change.  If 
no  occurrences  satisfy  the  selection-criteria,  the  change  is  not  made  for 
that  record. 

The  change-part  specifies  the  field  and  its  new  value.  The  value,  which  may 
be  expressed  as  a restricted-numeric-expression,  must  be  compatible  with 
the  data-type  defined  for  that  field.  For  multioccur ring  fields,  the  desired 
value  occurrence  to  be  changed  may  be  specified  by  denoting  its  old  value. 

If  more  than  one  value  occurrence  equals  this  old  value,  it  is  changed  to  the 
new  value.  If  no  occurrences  equal  the  old  value,  no  changes  are  made. 
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If  a multivalued  field  is  referenced  in  a change-part  where  no  old  value 
occurrence  is  specified,  all  old  occurrences  are  deleted  and  the  field  is 
set  to  a new  value  where  it  becomes  its  only  value  occurrence. 

■A.  4.  4.  E.  4 ADD  Statement.  The  ADD  statement  allows  a user  to  add  new 
value  occurrences  to  repeating  groups  or  multivalued  fields  for  a set  of 
records.  The  records  must  have  been  previously  isolated  by  a FIND  state- 
ment whose  statement  label  is  referenced  by  the  ADD  statement.  The  record 
source  specification  is  mandatory  for  the  ADD  statement.  All  specified 
records  will  have  the  additions  made  to  them. 

The  primary  component  of  the  ADD  statement  is  the  add-list.  The  add-list 
is  composed  of  add- elements,  qualified  or  unqualified.  Qualified  add- 
elements  are  valid  for  repeating  groups  only,  where  the  selection-criteria 
inside  the  OCC  parameter  isolates  the  repeating  group  occurrence  the 
addition  is  applicable  for.  As  was  the  case  with  the  CHANGE  statement,  depend- 
ing on  the  selectivity  of  the  criteria,  one  or  many  repeating  group  occur- 
rences may  be  affected.  If  no  occurrences  satisfy  the  selection  criteria, 
the  addition  is  not  made  for  that  record. 

Either  new  value  occurrences  to  multivalued  fields  or  new  occurrences  to  a 
hierarchical  structure  (a  tree  of  repeating  groups)  may  be  added.  If  a new 
value  occurrence  is  to  be  added  to  a multivalued  field,  it  must  be  compatible 
with  the  data-type  defined  for  that  field.  If  a new  repeating  group  occur- 
rence is  to  be  added,  all  major  fields  must  be  initialized  with  data.  As  was 
the  case  with  the  CREATE  statement,  this  process  may  be  nested  where 
many  levels  of  repeating  groups  can  be  added. 
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A.  4.  4.  2.  5 DELETE  Statement.  The  DELETE  statement  allows  a user  to 
delete  value  occurrences  from  repeating  groups  or  multivalued  fields  for  a 
set  of  records.  The  records  must  have  been  previously  isolated  by  a FIND 
statement  whose  label  is  referenced  by  the  DELETE  statement.  The  record 
source  specification  is  mandatory  for  the  DELETE  statement.  All  specified 
records  will  have  the  deletions  made  to  them. 

The  delete-list  is  the  primary  component  of  the  DELETE  statement.  The 
delete-list  is  composed  of  delete- elements,  qualified  or  unqualified. 

Qualified  delete-elements  are  valid  for  repeating  groups  only,  where  the 
selection- c riteria  inside  the  OCC  parameter  isolates  those  repeating  group 
occurrences  the  deletion  is  applicable  for.  As  was  the  case  for  the  CHANGE 
and  ADD  statements,  depending  on  the  selectivity  of  the  criteria,  one  or 
many  occurrences  may  be  affected.  If  no  occurrences  satisfy  the  selection- 
criteria,  the  deletion  is  not  made  for  that  record. 

Either  a value  occurrence  of  a multivalued  field  or  an  entire  occurrence  of 
a repeating  group  may  be  deleted.  If  all  the  occurrences  of  a mul’.ivalued 
field  are  to  be  deleted,  only  tlie  field-name  must  be  specified.  If  a selecced 
value  occurrence  is  to  be  deleted,  it  must  be  specified.  The  deletion  will 
occur  ortly  if  the  old  value  occurrence  is  present.  Multivalued  fields  occur- 
ring in  repeating  groups  may  have  value  occurrences  deleted.  However, 
if  this  field  is  declared  as  a major  field,  all  of  its  value  occurrences  cannot 
be  deleted.  If  a repeating  group  occurrence  is  deleted,  all  occurrences  of 
subordinate  repeating  groups  of  that  instance  are  also  deleted. 

A.  4.  5 UDL  Data  Manipulation  Statements 


A.  4.  5.  1 Assignment  Statement.  The  assignment  statement  allows  a value  j 

S 

to  be  assigned  to  a variable.  j 


A.  4.  5.  1.  1 Syntax. 


r 


i 
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<assignment-statement>  = <variable -term>  = <numeric-expression> 
<variable-ternn>  = @ < variable -naine> 

A.  4.  5.  1.  2 Semantic s.  The  assignment  statement  assigns  a value  to  the 
variable  based  on  the  evaluation  of  a numeric -expression.  UDL  recog- 
nizes two  variable  modes:  implicit  and  explicit.  Implicit  variables  are 
defined  by  their  usage  as  the  "left-hand- side"  of  an  assignment  statement. 
Explicit  variables  are  previously  defined  by  the  user  with  the  DECLAJIE 
statement  (paragraph  A.  4.  5.  4).  Implicit  variables  assume  the  data  type 
of  the  "right-hand- side.  " Explicit  variables  take  on  the  scaling  that  is 
defined  for  them.  Table  A-4  shows  the  valid  "left-hand- side /right-hand- 
side"  combinations  for  the  assignment  statement  with  respect  to  explicit 
variables. 

A.  4.  5.  2 CALLi  Statement.  The  CAXiL  statement  enables  the  user  to 
transfer  control  to  a predefined  procedure. 


A.  4.  5.  1 Syntax. 


i 


<call-  statement> 
<call-clause> 

<procedure -parameters 

< input  - par amete  r s> 

< output  - exit  - par  ame  t e r s> 

< output  - par  amete  r s> 

<exit-parameters> 


CALL  <call-clause> 

<procedure-name>  <procedure-parameter s>| 
<procedure-name> 

< input  - pa  rameters>,  <output-exit-parameter  s>| 
<input-parameter s>  | <output-exit-parameter s> 
<numeric-expression> , <input-parameter s>  1 
<nume  r ic  - expr  e s 3ion> 

<output-parameter s> , <exit-parameter s>| 

< output -parameters>  i <exit-parameter  s> 

<variable -term> , < output -pa r ame ters>  | 

< var  iable  s - 1 e rm> 

<tag>,  <exit-parameters>  | <tag>  ^ 

; 
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r 


t 

r 


F. 


TABLE  A-4. 


LEGAL  "LEFT-HAND-SIDE/RIGHT-HAND-SIDE"  COMBI- 
NATIONS FOR  THE  ASSIGNMENT  STATEMENT. 


R 

L 

Character 

Numeric 

Geographic 

1 

1 

Character 

Yes 

Yes 

Yes 

Numeric 

— 

Yes 

— 

Geographic 

_ 

Yes 

(where  the  "left-hand -side"  is  an  explicit  variable) 
"Right-hand-side"  is  converted  to  character. 

A.  4.  5.  2.  2 Semantics.  The  CALL  statement  will  cause  control  to  be  trans- 
ferred to  the  named  procedure,  with  accompanying  parameters.  The  proce- 
dure will  be  executed,  and  control  will  be  returned  to  the  calling  procedure 
or  batch.  The  parameters  must  be  specified  in  the  same  order  as  they  are 
defined  in  the  PROCEDURE  statement.  Control  is  returned  via  an  EXIT 
statement  to  eitlier  tlie  statement  following  the  CALL  statement  or  to  another 
statement  w'hosc  label  is  specified  as  an  exit  parameter  (abnormal  exit). 

A.  4.  5.  3 CLEAR  LIST  Statement.  The  CLEAR  LIST  statement  removes  all 
records  from  tlic  named  list. 


I 

i 

J 


J 


i 

I 


Ji 

f 

A 


134 


Report  76-C-0899-1 


A 4.  5.  3.  1 Syntax. 

<clear-list-statement>  = CLEAR  LIST  <clear-list-clause> 

<clear-list-clause>  = <list-name-list>  | ALL 

<list-name-list>  = <list-name>  , <list-name-list>  | <list-name> 

<list-name>  = <name> 

A.  4.  5.  3.  2 Semantics,  The  named  list  does  not  disappear  from  existence 
when  this  statement  is  executed:  it  only  becomes  clear  of  record  images. 

If  ALL  is  specified,  all  lists  for  this  user  are  cleared. 

A.  4.  5.  4 DECLARE  Statement.  The  DECLARE  statement  defines  a variable 
and  describes  its  characteristics. 


A 4.  5.  4.  1 Syntax. 

<declare-  statement> 
<declare-clause> 

<character-phrase> 

<character-element> 

<numeric-phrase> 
<numeric  - element> 

<geographic-phrase> 

<pre set- value  1> 
<preset-value2> 

<pre set- value  3> 
<preset-value4> 

<size -scale -specification> 
<size-specification> 


; 

= DECLARE  <variable-name>  <declare-clause> 

= <character-phrase>  | <numeric-phrase>  | 
<geographic-phrase> 

= CHAR  <character- element> 

= <size- specification>  <preset-value  1>  | 

<size- specification> 

= NUM  <numeric-element> 

= <size- scale- specification>  <preset- value2>  [ 

<size- scale -specification>  I E <pre set- value 3>iE 
= GEO  <preset-value4>  | GEO 
= <character-constant> 

= <fixed-point-constant> 

= <floating-point-const2uit> 

= <geographic-constant> 

= <digit>  / <digit>  ] <digit> 

= <digit>  <size-specification>  | <digit> 


r ' 
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A.  4.  5.  4.  2 Semantics.  The  name  of  the  variable  is  specified  along  with  its 
type  (character,  numeric,  or  geographic).  For  variables  designated  as 
character,  a size- specification  is  mandatory,  where  it  specifies  the  maxi- 
mum number  of  characters  the  variable  may  contain.  Fixed-point  variables 
must  also  have  a size  specified  where  it  denotes  the  maximum  number  of 
decimal  digits  the  variable  may  contain.  An  optional  scaling  specification 
may  be  placed  on  fixed-point  variables,  where  it  denotes  the  number  of  frac- 
tional decimal  digits  for  that  variable.  All  variables  may  be  preset  with  an 
appropriate  data- constant. 

A.  4.  5.  5 DO  Statement.  The  DO  statement  allows  execution  of  a UDL  state- 
ment sequence  a specified  number  of  times.  The  number  of  times  is 
specified  via  a series  of  values  a variable  will  assume. 


A.  4.  5.  5.  1 Syntax. 


<do-  statement> 
<do-  specification> 
<do- element- list> 

<do-element> 


< max- specification> 
<rgn-list> 


DO  <do- specification>  END  (<tag>) 

<variable-term>  = <do-element-list> 

<do-element>  , <do- element- list>  | 

<do-element> 

<numeric-expression>  TO  <max- specification> 

BY  <numeric-expression>  I <numeric-expression> 
TO  <ma.x- specification>  I <numeric-expression> 
MAX  '<rgn-list>)  | <numeric-expression> 
<repeating-group-name>  , <rgn-list>  I 
<rcpeating-group-name> 


A.  4.  5.  5.  2 Semantics.  The  DO  statement  establishes  a loop  or  a set  of 
loops  based  on  the  values  a specified  variable  will  assume.  A single  loop 
is  defined  by  its  initial  value,  its  final  value,  and  the  increment  used  as  the 
loop  is  transgressed.  If  an  increment  is  not  specified,  an  increment  of  one 
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is  assumed  as  a default  value.  If  a final  value  is  not  specified,  the  loop  is 
processed  exactly  once,  where  the  variable  is  set  to  the  specified  initial 
value.  The  max- specification  can  be  either  a numeric-expression  or  a list 
of  repeating- groups.  If  MAX  is  specified,  the  final  value  assumes  the  maxi- 
mum occurrence  of  the  repeating- group  list.  Refer  to  paragraph  A.  4.  3.  2 
for  more  information  on  the  MAX  qualifier. 

The  scope  of  the  DO  loop  is  a set  of  UDL  statements  starting  with  the  UDL 
statement  immediately  following  the  DO  statement  and  ending  with  the  state- 
ment pointed  to  by  tag.  All  statements  within  the  DO  loop  assume  a state- 
ment level  one  greater  than  the  DO  statement,  and,  therefore,  if  a user 
assigns  statement  labels  within  a DO  loop,  they  must  reflect  this  condition. 

A.  4.  5.  6 DO  OCCURRENCE  Statement.  The  DO  OCCURRENCE  statement 


allows  execution  of  a UDL  statement  sequence  a specified  number  of  times. 
The  number  of  times  is  specified  by  the  number  of  occurrences  in  a specified 
data  structure. 


A.  4.  5.  6.  1 Syntax. 

<do-occurrence-statement>  = DO  OCCURRENCE  <occurrence-clause>  END 


<occurrence-clause> 


(<tag>) 

= <field-term>  | <repeating- group-term> 


A 4.  5.  6.  2 Semantics.  The  DO  OCCURRENCE  statement  establishes  a loop 
based  on  the  number  of  occurrences  contained  in  a specified  field  or  repeat- 
ing group.  The  DO  OCCURRENCE  statement  must  be  inside  a DO  RECORD 
loop,  which  establishes  the  record  source. 

The  scope  of  the  DO  OCCURRENCE  loop  is  a set  of  UDL  statements  imme- 
diately following  the  DO  OCCURRENCE  statement  and  ending  with  the  state- 
ment pointed  to  by  tag.  All  statements  within  the  DO  OCCURRENCE  loop 
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assume  a statement  level  one  greater  than  the  DO  OCCURRENCE  statement, 
and,  therefore,  if  a user  assigns  statement  labels  within  the  DO  loop,  they 
must  reflect  this  condition.  In  the  UDL  data  structure  description  (para- 
graph A.3. 1.2.2),  six  examples  are  presented  which  show  the  use  of  the  DO 
, OCCURRENCE  statement  and  its  interaction  with  repeating  groups  and 
multivalued  fields.  Table  A- 5 shows  which  UDL  statements  are  affected 
when  placed  inside  a DO  OCCURRENCE  loop. 

A.  4.  5.  7 DO  RECORD  Statement.  The  DO  RECORD  statement  allows  execu- 
tion of  a UDL  statement  sequence  a specified  number  of  times.  The  number 
of  times  is  specified  by  the  number  of  records  contained  on  a list. 

A.  4.  5.  7.  1 Syntax. 

<do- record- statement>  = DO  RECORD  END  (<tag>)  SOURCE 

{<source-argument>) 

- <source-argument>  = <tag>  | <list-name> 

A.  4.  5.  7.  2 Semantics.  The  DO  RECORD  statement  establishes  a loop  based 
on  the  number  of  records  contained  on  a named  list  or  an  implicit  list 
generated  by  a FIND  statement. 

The  scope  of  the  DO  RECORD  loop  is  a set  of  UDL  statements  immediately 
following  the  DO  RECORD  statement  and  ending  with  the  statement  pointed  to 
by  tag.  All  statements  within  the  DO  RECORD  loop  assume  a statement  level 
one  greater  than  the  DO  RECORD  statement;  therefore,  if  a user  assigns 
statement  labels  within  the  DO  loop,  they  must  reflect  this  condition. 

Table  A-6  shows  which  UDL  statements  are  affected  when  placed  inside  a 
DO  RECORD  loop. 
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TABLE  A- 5.  UDL  STATEMENT  OCCURRENCES  INSIDE 
A DO  OCCURRENCE  LOOP. 


Statement 

Affected 

Mandatory 

niegal 

ADD 

No 

- 

- 

Assignment 

Yes 

- 

- 

CALL 

No 

- 

- 

CHANGE 

No 

- 

- 

CLEAR 

No 

- 

- 

CREATE 

No 

- 

- 

DECLARE 

- 

- 

Yes 

DELETE 

No 

- 

- 

DISPLAY 

Yes 

- 

- 

DO 

Yes 

- 

- 

DO  OCCURRENCE 

Yes 

- 

- 

DO  RECORD 

Yes 

- 

- 

DO  VALUE 

Yes 

- 

- 

FIND 

No 

- 

- 

FORMAT 

- 

- 

Yes 

GOTO 

No 

- 

- 

HEADER 

- 

- 

Yes 

IF 

Yes 

- 

- 

OFF 

No 

- 

- 

ON 

No 

- 

- 

PROCEDURE 

- 

- 

Yes 

PULL 

No 

- 

- 

PUT 

No 

- 

- 

REMOVE 

No 

- 

- 

SORT 

Yes 

- 

- 

TABSET 

No 

- 

- 

TRAILER 

• 

Yes 
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TABLE  A-6.  UDL  STATEMENT  OCCURRENCES  INSIDE 
A DO  RECORD  LOOP. 


Statement 

Affected 

Mandatory 

Illegal 

ADD 

No 

- 

- 

Assignment 

Yes 

Yes  ^ 

• M 

CALL 

No 

- 

- 

CHANGE 

No 

- 

- 

CLEAR 

No 

- 

ii 

CREATE 

No 

- 

DECLARE 

- 

- 

Yes  If 

DELETE 

No 

- 

-J-j 

DISPLAY 

Yes 

- 

1 

DO 

Yes 

Yes^ 

* 

DO  OCCURRENCE 

Yes 

Yes 

) 

] 

DO  RECORD 

Yes 

- 

DO  value 

Yes 

- 

J 

FIND 

No 

- 

i 

FORMAT 

- 

- 

Yes  J 

GOTO 

No 

- 

1 

HEADER 

- 

- 

Yes  J 

IF 

Yes 

Yes  ^ 

1 

OFF 

No 

- 

- 

ON 

No 

- 

PROCEDURE 

- 

- 

Yes 

PULL 

Yes 

Yes 

. 

PUT 

Yes 

- 

. 

REMOVE 

No 

- 

_ 

SORT 

Yes 

- 

- 

TABSET 

No 

- 

1 : 

TRAILER 

- 

- 

Yes  ^ 

If  data-names  are  referenced  and  the  statement  is  not  inside  a 

DO  VALUE  1 

loop. 
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A.  4.  5.  8 DO  VALUE  Statement.  The  DO  VALUE  statement  allows  execution 
of  a UDL  statement  sequence  a specified  number  of  times.  The  number  of 
times  is  specified  by  the  number  of  unique  values  occurring  in  a specified 
field. 

A.  4.  5.  8.  1 Syntax. 

<do- value-  statement> 

<do- value- clause> 

<end-clause> 

<source-  specification> 

<source-argument> 

A.  4.  5.  8.  2 Semantics.  The  DO  VALUE  statement  establishes  a loop  based 
on  the  number  of  unique  value  occurrences  contained  in  a multivalued  field. 
The  DO  VALUE  statement  may  optionally  be  inside  a DO  RECORD  loop, 
where  the  record  source  is  established  and  controlled.  If  the  DO  VALUE 
statement  is  not  inside  a DO  RECORD  loop,  the  record  source  must  be 
specified  in  the  DO  VALUE  statement.  Any  reference  to  the  multivalued 
field  specified  in  the  DO  VALUE  statement  by  a statement  inside  the  DO 
VALUE  loop  will  reference  the  value  occurrence  that  is  currently  active. 


= DO  VALUE  <field-term>  <do- value-clause> 
= <end-clause>  <source- specification>  | 
<end-clause> 

= END  (<tag>) 

= SOURCE  (<source-argument>) 

= <tag>  I <list-name> 


■f  The  scope  of  the  DO  VALUE  loop  is  a set  of  UDL  statements  immediately 

( 

I following  the  DO  VALUE  statement  and  ending  with  the  statement  pointed  to 

[ by  tag.  All  statements  within  the  DO  VALUE  loop  assume  a statement  level 

[ 

I one  greater  than  the  DO  VALUE  statement,  and,  therefore,  if  a user  assigns 

statement  labels  within  the  DO  loop,  they  must  reflect  this  condition. 

Table  A- 7 shows  which  UDL  statements  arc  affected  when  placed  inside  a DO 
VALUE  loop.  The  value- set  looped  on  is  determined  either  from  all  values 
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TABLE  A-7.  UDL  STATEMENT  OCCURRENCES  INSIDE 
A DO  VALUE  LOOP. 


Statement 


Assignment 

CALL 

CHANGE 

CLEAR 

CREATE 

DECLARE 

DELETE 

DISPLAY 


DO  OCCURRENCE 

DO  RECORD 

DO  VALUE 

FIND 

FORMAT 

GOTO 

HEADER 


OFF 


Affected 


Mandatory 


Illegal 


PROCEDURE 

PULL 

PUT 

REMOVE 

SORT 

TABSET 

TRAILER 


If  data-names  are  referenced  and  the  statement  is  not  inside 
RECORD  loop. 


a DO 


pp|  - nwi  I M I I I1IWIPWIIPI»^»WII.IUI,IWIWWI  iiiiiwiwiiiuwi^^p^^W^IWWWPPWWIBBPPliWIIIWWWIWpWWlPWMM 
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i 

• • 

; the  field  contains  in  a single  record  if  the  DO  VALUE  statement  is  under  the 

I ^ ' 

control  of  a DO  RECORD  loop,  or  all  values  the  field  contains  in  all  records. 

For  the  latter  case,  the  DO  VALUE  statement  specifies  its  own  record 
source. 

'% 

A.  4.  5.  9 EPROC  Statement.  The  EPROC  statement  ends  the  definition 
of  a procedure. 

A 4.  5.  9.  1 Syntax. 

<end-procedure- statement>  = EPROC  <procedure-name> 

A.  4.  5.  9.  2 Semantics.  All  statements  between  the  PROCEDURE  statement 
and  the  EPROC  statement  with  matching  procedure -names  become  the 

■ 

[ * defined  procedure.  All  UDL  procedures  must  have  a matching  PROCEDURE/ 

: EPROC  statement  pair, 

i 

, A.  4.  5.  10  EXIT  Statement.  The  EXIT  statement  allows  control  to  be  \ 

[ ‘ ' returned  from  a procedure  back  to  the  batch  or  procedure  which  called  it. 

r 

■ • A.  4.  5.  10.  1 Syntax. 

[ . 

[ <exit-statement>  = EXIT 

A.  4.  5.  10.  2 Semantics.  If  the  statement  label  on  the  EXIT  statement  is 
named  as  an  exit  parameter  in  the  PROCEDURE  statement,  the  EXIT  is  an 
abnormal  exit  from  the  procedure  and  control  is  returned  to  the  corres- 
ponding statement  label  specified  in  the  CALL  statement.  If  the  label  on  the 
EXIT  statement  is  not  named  as  an  exit  parameter  in  the  PROCEDURE 
( statement,  it  is  a normal  exit  and  control  is  returned  to  the  statement 

following  the  CALL  to  the  procedure. 


A.  4.  5.  1 1 GOTO  Statement.  The  GOTO  statement  changes  execution 
control  from  one  sequence  of  UDL  statements  to  another  sequence  of  UDL 
statements. 


A.  4.  5.  11.  1 Syntax. 

<go-to-statement>  = GOTO  <go-to-clause> 

<go-to-clau£'e>  = <tag>  | <computed-go-to-phrase> 

<computed-go-to-phrase>  = (<tag-list>)  <numeric-expression> 

<tag-list>  = <tag>  , <tag-list>  | <tag> 

A.  4.  5.  11.  2 Semantics.  There  are  two  forms  of  the  GOTO  statement: 

a.  Unconditional  GOTO:  GOTO  <tag>.  When  this  statement  is  executed, 
control  is  unconditionally  transferred  to  the  statement  whose  label 

is  specified  by  tag. 

b.  Computed  GOTO:  GOTO  (<tag-list>)  <numeric-expression>.  When 
this  statement  is  executed,  the  numeric-expression  is  evaluated, 
the  result  is  truncated  to  an  integer  value,  and  this  result  is  used 
as  an  index  into  the  tag-list.  If  the  truncated  result  of  the  numeric- 
expression  is  less  than  one  or  greater  than  the  number  of  tags  in 
the  list,  control  is  transferred  to  the  next  statement.  Otherwise, 
control  is  transferred  to  the  statement  whose  label  in  the  list  corre- 
sponds to  the  truncated  value  of  the  expression. 


A.  4.  5.  12  IF  Statement.  The  IF  statement  allows  execution  of  a UDL  state- 
ment sequence  if  a specified  boolean  expression  is  satisfied,  or  a different 
UDL  statement  sequence  if  the  boolean  expression  is  not  satisfied. 

A.  4.  5,  12.  1 Syntax. 

<if- statement>  r IF  <boolean- expres sion>  <thon- else-block> 

<then-else-block>  = <then-block>  <else-block>  | <then-block> 

<then-block>  = THEN  <statement-block> 

<else-block>  = ELSE  <statement-block> 

<statemont-block>  = "block  of  UDL  statements" 
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A.  4.  5.  12.  2 Semantics.  If  the  boolean-expression  is  satisfied,  the  then- 
block  is  executed.  If  the  boolean-expression  is  not  satisfied,  either  the  else- 
block  is  executed  (if  specified)  or  the  first  statement  following  the  IF  state- 
ment with  the  same  level  as  the  IF  statement  is  executed.  Both  the  then- 
block  and  the  else-block  must  exist  at  one  statement  level  below  that  of  the 
IF  statement,  hence  all  user- specified  labels  in  this  block  must  reflect  this 
condition. 

All  UDL  statements  are  legal  in  the  statement-block  except  the  following; 

a.  PROCEDURE. 

b.  DECLARE. 

c.  EXIT. 

d.  EPROC. 

e.  HEADER. 

f.  TRAILER. 

g.  FORMAT. 

A 4.  5.  13  PROCEDURE  Statement.  The  PROCEDURE  statement  begins  the 
definition  of  a procedure.  It  also  specifies  the  name  of  the  procedure  and 
the  parameters  used  in  the  procedure. 

A 4.  5.  13.  1 Syntax. 

<procedure- statcmcnt>  = PROCEDURE  <procedure-clause> 

<procedure-clausc>  = <procedure-name>  <procedure-parameters>  | 

<procedure-name> 

<procedure-parametcrs>  = <input-parameters>  <out-exit-parameters>  | 

<input-parameters>  | <out-exit-parameters> 
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<input-parameters>  = INPUT  (<input-parameter-list> ) 

<out-exit-parameters>  = <output-parameters>  <exit-parameters>  | 

<output-paraineters>  | <exit-parameter3> 
<output-parameters>  = OUTPUT  (<output-parameter-list> ) 

<exit-parameters>  = EXIT  (<tag-li3t>) 

< input- par ameter-list>  = <numeric-expression> , <input-parameter- 

list>  I <numeric -expressions 

<output -parameter -lists  = < variable -terms,  <output-parameter-lists  | 

< variable -terms 

<tag-lists  = <tags,  <tag-lists  [ <tags 

A,  4.  5,  13.  2 Semantics.  All  the  statements  between  the  PROCEDURE 
statement  and  the  EPROC  statement  with  matching  procedure  names 
become  the  defined  procedure.  Procedures  cannot  be  defined  inside  other 
procedures.  There  are  three  types  of  parameters  that  may  be  specified 
with  the  PROCEDURE  statement:  input,  output,  and  exit  (abnormal). 

Input  parameters  are  indicated  via  the  INPUT  key  word  and  supply  input 
values  to  the  procedure.  Input  values  may  be  simple  data-constants, 
fields-names,  or  complex  numeric-expressions.  Output  parameters  are 
indicated  via  the  OUTPUT  key  word  and  will  carry  output  values  from  the 
execution  of  the  procedure.  Output  parameters  are  limited  to  variables. 
Exit  parameters  are  indicated  via  the  EXIT  key  word  and  specify 
abnormal  exits  from  the  procedure.  An  abnormal  exit  is  one  in  which 
control  does  not  return  to  the  statement  following  the  CALL  to  the 
procedure  but  to  some  other  statement  whose  label  is  specified  in  the 
CALL  statement.  Although  the  parameters  specified  in  the  CALL  state- 
ment are  not  preceded  by  the  key  words  INPUT,  OUTPUT,  and  EXIT, 
these  parameters  must  be  in  the  same  order  as  the  parameters  defined 
for  the  procedure  (in  the  PROCEDURE  statement). 
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A.  4.  5.  14  PULL  Statement.  The  PULL  statement  removes  a record  from 
a list. 

A.  4.  5.  14.  1 Syntax. 

<pull- statement>  = PULL 

A.  4.  5.  14.  2 Semantics.  The  PULL  statement  must  be  inside  a DO  RECORD 
loop.  The  record  to  be  removed  from  the  list  is  a single  record  which  is 
the  current  record  in  a DO  RECORD  loop.  If  this  is  the  only  record  on  the 
list,  the  list  becomes  empty  but  is  still  defined  for  the  user. 

A.  4.  5.  15  PUT  Statement.  The  PUT  statement  places  a record(s)  on  a list. 

A.  4.  5.  15.  1 Syntax. 

<put- statement>  = PUT  <put-clause> 

<put-clause>  = <list-name>  SOURCE  (<source-argument>)  J 

<list-name> 

<source-argument>  = <tag>  | <list-name> 

<list-name>  = <name> 

A 4.  5.  15.  2 Semantics.  The  record(s)  to  be  placed  on  the  list  named  by 
list-name  is  either  a single  record  which  is  the  current  record  in  a DO 
RECORD  loop,  or  is  one  or  more  records  pointed  to  by  source-argument. 

If  the  list  does  not  already  exist  at  the  time  this  statement  is  executed,  it 
is  created  at  this  time. 

A 4.  5.  16  SORT  Statement.  The  SORT  statement  sorts  a list  of  records. 
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A.  4.  5.  16.  1 Syntax. 

< sort-statenient> 

< source-argument> 

<key-list> 

<key-element> 

<key-qualifier> 

A.  4.  5.  16.  2 Semantics.  The  list  of  records  to  be  sorted  is  either  an 
implicit  list  (i.  e.  , the  records  isolated  by  a previous  FIND  statement, 
named  as  source-argument)  or  an  explicit  list  named  as  source-argument. 

The  order  is  specified  by  the  key-list  which  implies  a major-to-minor 
order  where  the  next  key  is  used  only  to  further  sort  equal  records  with 
respect  to  the  previous  key.  The  order  is  ascending  unless  DESCEND  is 
specified.  The  NUMERIC  qualifier  is  used  for  character  type  fields  when 
a numeric  rather  than  an  alphanumeric  sort  is  desired.  If  the  field 
specified  in  field-term  is  multi-valued,  the  first  occurrence  is  used  for 
the  sort.  Upon  completion  of  the  SORT  statement,  an  implicit  list  is 
constructed  which  contains  the  sorted  records.  This  list  can  be 
referenced  by  the  SORT  statement  label,  which  must  be  present. 


= SORT  SOURCE  (<source-argument> ) <key-list> 
= <tag>  I <list-name> 

= <key-element'>,  <key-list>  | <key-element> 

= <field-term>  <key-qualifier>  i <field-term> 

= DESCEND  NUMERIC  | DESCEND  | NUMERIC 
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